On Mon, Nov 2, 2009 at 4:27 AM, Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxx> 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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
