[alsa-devel] snd-hda-intel: no data when recording from mic, "IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj" logged in kern.log

[Takashi Iwai]

At Wed, 23 Sep 2009 00:46:41 +0200,
Aleksander Adamowski wrote:
> 
> Hi!
> 
> I think I have some interesting problems to analyse for Takashi.
> 
> Maybe my sound card model is a non typical one, but I have a
> continuous stream of capture-related problems with it.
> 
> It's an integrated sound card on my Gigabyte GA-MA74GM-S2H Rev. 1.1 motherboard.
> 
> "grep ^Codec /proc/asound/card0/codec#0" shows:
> Codec: Realtek ALC888
> 
> I'm attaching the full contents of /proc/asound/card0/codec#0 for
> identification.
> 
> But first, some background.
> 
> With this particular card, I've been continuously hit by the
> "azx_get_response timeout, switching to single_cmd mode" problem,
> described here:
> http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html#_codec_probing_problem
> 
> However, in my case setting probe_mask=1 (experimentally determined)
> didn't make the problem go away, although it seemed to reduce its
> frequency (might be just a coincidence).
> 
> Whenever the dreaded "azx_get_response timeout, switching to
> single_cmd mode" message appeared in the kernel log, recording stopped
> working.
> 
> The card got into the bad state where it would not record sound, and
> arecord would be giving a stream of "overrun" error messages:
> 
> arecord -f cd output.wav
> Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
> overrun!!! (at least 27.876 ms long)
> overrun!!! (at least 26.965 ms long)
> overrun!!! (at least 16.169 ms long)
> overrun!!! (at least 11.749 ms long)
> overrun!!! (at least 11.298 ms long)
> overrun!!! (at least 11.814 ms long)
> overrun!!! (at least 11.190 ms long)
> overrun!!! (at least 11.190 ms long)
> overrun!!! (at least 11.747 ms long)
> overrun!!! (at least 11.819 ms long)
> overrun!!! (at least 11.149 ms long)
> overrun!!! (at least 11.257 ms long)
> overrun!!! (at least 11.315 ms long)
> overrun!!! (at least 11.651 ms long)
> overrun!!! (at least 11.745 ms long)
> overrun!!! (at least 11.235 ms long)
> overrun!!! (at least 11.169 ms long)
> overrun!!! (at least 11.776 ms long)
> overrun!!! (at least 11.391 ms long)
> overrun!!! (at least 11.669 ms long)
> overrun!!! (at least 11.714 ms long)
> overrun!!! (at least 11.671 ms long)
> overrun!!! (at least 11.190 ms long)
> 
> What's notable, sound playback would continue to work OK.
> 
> After being fed up with interrupted Skype conversations (where I
> weren't immediately aware that the other side stopped hearing me,
> since I was hearing them), I've decided to upgrade do kernel 2.6.29
> (citing the http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html#_codec_probing_problem
> document: "Since 2.6.29 kernel, the driver has a more robust probing
> method, so this error might happen rarely, though").
> 
> After upgrading to 2.6.29 I've removed any extra snd-hda-intel options
> from modprobe config files.
> 
> Now the azx_get_response timeout seems to be gone, but I'm
> experiencing another problem: after some powered up time, recording
> starts giving empty streams - there's no error, but audio data has
> zero lengh.
> 
> e.g. when I arecord, I get a .wav file that is only 44 bytes long
> (which seems to be the length of the WAV header). When I make a Skype
> test call to echo123, and it starts playing back my message, it's zero
> length too - the playback end signal can be heard immediately after
> the playback start signal.
> 
> This problem seems to concide with the following error message in the
> kernel log:
> hda-intel: IRQ timing workaround is activated for card #0. Suggest a
> bigger bdl_pos_adj.
> 
> Do you have any idea what could be the cause and how to debug this
> issue further?

First off, try the very latest alsa-driver snapshot.
2.6.29 is already very old, and there have been bunch of fixes and
improvements since then.

Also, load the driver with model=auto option, too.

If both don't help, please attach alsa-info.sh output (run with
--no-upload option) to analyze more.


thanks,

Takashi