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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
