[alsa-devel] Handling HDA FIFO error
Hi,
On the OLPC XO-1.5 (VIA VX855 SoC with HDA) we sometimes see a problem where audio playback fails. Easy to reproduce by playing a short wav file in a loop, it will fail after a minute or two.
The playback app gets confused here: snd_pcm_wait() returns success, but snd_pcm_writei() returns EAGAIN.
Digging into the HDA code, I can see that normally, when the stream gets started, we get interrupts with SD_STS as 0x24. In the failure case, as soon as we start the stream, we get a flood of interrupts with SD_STS 0x8 - which indicates FIFO error.
Disabling interrupt generation upon FIFO error does not help much - it avoids the flood of interrupts, but doesn't change the fact that audio playing apps hang or loop infinitely.
I have tried the various position_fix options with no luck.
Are there any things I could check that would explain why a FIFO error might be occurring? After a quick read of the HDA spec I don't really understand what this FIFO actually is and what it does, how does it relate to the BDL, CORB and RIRB?
Failing that... any suggestions for how to improve the hda_intel driver to handle FIFO error gracefully? Right now there is no code to handle that.
Thanks Daniel
Daniel Drake wrote:
Digging into the HDA code, I can see that normally, when the stream gets started, we get interrupts with SD_STS as 0x24. In the failure case, as soon as we start the stream, we get a flood of interrupts with SD_STS 0x8 - which indicates FIFO error.
Disabling interrupt generation upon FIFO error does not help much - it avoids the flood of interrupts, but doesn't change the fact that audio playing apps hang or loop infinitely.
Are there any things I could check that would explain why a FIFO error might be occurring?
Probably a buffer underrun, i.e., the controller did not manage to read samples from memory fast enough.
any suggestions for how to improve the hda_intel driver to handle FIFO error gracefully? Right now there is no code to handle that.
It should stop the stream, i.e., go into the xrun state.
In theory, the application restarting the stream should reset the DMA engine enough to make it work again. But you say this happens also when starting the stream, so I guess more resetting is needed.
Regards, Clemens
At Wed, 15 May 2013 11:08:55 +0200, Clemens Ladisch wrote:
Daniel Drake wrote:
Digging into the HDA code, I can see that normally, when the stream gets started, we get interrupts with SD_STS as 0x24. In the failure case, as soon as we start the stream, we get a flood of interrupts with SD_STS 0x8 - which indicates FIFO error.
Disabling interrupt generation upon FIFO error does not help much - it avoids the flood of interrupts, but doesn't change the fact that audio playing apps hang or loop infinitely.
Are there any things I could check that would explain why a FIFO error might be occurring?
Probably a buffer underrun, i.e., the controller did not manage to read samples from memory fast enough.
any suggestions for how to improve the hda_intel driver to handle FIFO error gracefully? Right now there is no code to handle that.
It should stop the stream, i.e., go into the xrun state.
In theory, the application restarting the stream should reset the DMA engine enough to make it work again. But you say this happens also when starting the stream, so I guess more resetting is needed.
Or possibly the coherency issue. Try to disable snoop option.
Takashi
On Wed, May 15, 2013 at 4:08 AM, Takashi Iwai tiwai@suse.de wrote:
At Wed, 15 May 2013 11:08:55 +0200, Clemens Ladisch wrote:
Daniel Drake wrote:
Digging into the HDA code, I can see that normally, when the stream gets started, we get interrupts with SD_STS as 0x24. In the failure case, as soon as we start the stream, we get a flood of interrupts with SD_STS 0x8 - which indicates FIFO error.
Disabling interrupt generation upon FIFO error does not help much - it avoids the flood of interrupts, but doesn't change the fact that audio playing apps hang or loop infinitely.
Are there any things I could check that would explain why a FIFO error might be occurring?
Probably a buffer underrun, i.e., the controller did not manage to read samples from memory fast enough.
That would seem logical, but I don't think this can be happening here. In this case the audio buffer is filled up with data before playback is started, and it only auto-starts right at the point when the buffer becomes full. Then immediately, the first interrupt that comes in says "FIFO error". The buffer was full at this point.
However I was unable to reproduce this FIFO error interrupt when revisiting the problem. Every time I go back to it with my test case of calling gst-launch in a loop, a different audio-related problem seems to pop up.
Digging further, I found some oddness with the device being powered up and down at the wrong times. I'm on Linux-3.3 here, so I threw in a load of the newer commits that fix the CONFIG_SND_HDA_POWER_SAVE functionality and now things seem to be working perfectly. Sorry for the noise and thanks for already having fixed this :)
Here is a patch anyway which could be used to handle the FIFO error interrupt. It hasn't reappeared so I haven't been able to test it.
Thanks, Daniel
participants (3)
-
Clemens Ladisch -
Daniel Drake -
Takashi Iwai