Hi all,I’m currently investigating a sporadic issue in our system where an audio interrupt is occasionally lost. When this happens, ALSA detects the anomaly (presumably through its internal timestamp or delay detection), but it doesn’t appear to take corrective action—leading to persistent audio jitter afterward.To address this, I’m considering implementing a mechanism in our driver or platform layer that uses a timer to check if the expected audio interrupt hasn’t arrived within a certain timeframe (e.g., 2x the period size). If this condition is met, I plan to explicitly trigger an XRUN to reset the pipeline and recover cleanly.My questions are:
1. Is this an acceptable and “ALSA-friendly” way to handle lost IRQs? 2. If this is a reasonable approach, why doesn’t ALSA do this by default? 3. Is there a better or recommended way within the ALSA framework to detect and recover from such missed interrupts?
I’d appreciate any guidance or suggestions. If this kind of timer-based recovery would be broadly useful, I’d also be happy to explore whether it could be proposed upstream.
Thanks, Sandeep