On Wed, 25 Jun 2025 05:29:43 +0200, Sandeep Verma wrote: > > 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? Yes, a XRUN detection in the driver side is fine, per se. > 2. If this is a reasonable approach, why doesn’t ALSA do this by default? Maybe a simple answer is that because it's a rare case. The PCM core has a correction of the lost interrupt at PCM pointer reporting, but it's done at updating the PCM pointer, e.g. via snd_pcm_period_elapsed() call. The detection of the lost interrupt is left to each driver, since there can be various mechanisms to do that. > 3. Is there a better or recommended way within the ALSA framework to > detect and recover from such missed interrupts? The recovery depends on the tolerance. The XRUN handling is a brute-force stop and restart. But it might be that you can simply ignore one lost interrupt if the buffer consists of many small periods, too. > 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. So feel free to submit your fix patch. But, for the kernel patches, please submit to linux-sound ML, instead of alsa-devel ML. thanks, Takashi
