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