On Mon, Nov 2, 2009 at 4:27 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 1 Nov 2009 14:03:18 -0600, Robert Hancock wrote:
On Fri, Oct 30, 2009 at 6:31 AM, Takashi Iwai tiwai@suse.de wrote:
At Thu, 29 Oct 2009 19:05:15 -0600, Robert Hancock wrote:
I've been using the VT1828S codec support from ALSA git for the last few weeks. It seems to work fine, but there are some problems showing up in dmesg:
Oct 25 20:46:14 newcastle kernel: ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x02af0900 Oct 25 20:46:15 newcastle kernel: ALSA sound/pci/hda/hda_intel.c:698: azx_get_response timeout, switching to polling mode: last cmd=0x02af0900
Note that this isn't always a severe problem. If polling mode works (you don't see the similar errors after this), it means the IRQ isn't properly generated at verb handling.
It seems like the cmd isn't always the same, previously it was 0x024f0c00. Is there something bad about this command that could be causing the response timeout?
Hm, both aren't really same, pointing to different widgets. So, it looks like a generic problem in the codec communication on your board.
Something VIA guys should look into?
Hopefully. This is a bit hard problem to track, though...
Also, disabling MSI for one occurrence of this seems a bit paranoid..
MSI was unstable for long time, so disabling it was a sane option :) Now it gets better, so it should be a second option. I changed the code now.
Also saw one of these:
Oct 26 21:13:20 newcastle kernel: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
and PulseAudio also complained:
Oct 26 00:27:50 newcastle pulseaudio[16530]: alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! Oct 26 00:27:50 newcastle pulseaudio[16530]: alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. Oct 26 00:27:50 newcastle pulseaudio[16530]: alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Well, this is the case where the hardware reports bad position data. This is usually a hardware bug, and hard to fix properly. We have some mechanism to correct or take back to the last position. This should usually work, but apparently not in your case...
Well, it looks like PulseAudio complained before the IRQ timing workaround was activated (about 20 hours earlier)..
Then try to pass bdl_pos_adj=0 option to snd-hda-intel module. The PA complaining still present?
With bdl_pos_adj=0, so far no complaints from PulseAudio after some hours of audio playing.. I'll keep monitoring it.
Actually there's been no codec response timeout errors either since making that change, though I don't know if it's just by luck.. doesn't seem like it should be related.