Re: pcm0:play:0: play interrupt timeout, channel dead

On Tue, 2004-09-07 at 22:57, Don Lewis wrote:
> On  7 Sep, Alexandre "Sunny" Kovalenko wrote:
> > On Tue, 2004-09-07 at 04:14, Guido van Rooij wrote:
> >> I have this problem when using skype. Normal sound playback via e.g.
> >> xmms goes well. This is on a Dell Latitude D600. 
> >> 
> >> Underneath my dmesg (witout ACPI,  with ACPI I get the same results).
> >> 
> >> > cat /dev/sndstat 
> >> FreeBSD Audio Driver (newpcm)
> >> Installed devices:
> >> pcm0: <Intel ICH4 (82801DB)> at io 0xf4fff800, 0xf4fff400 irq 11 bufsz 16384 (1p/1r/0v channels duplex default)
> >> 
> >> 
> > There is an odd looking bit of code in
> > /usr/src/sys/dev/sound/pcm/channel.c (function chn_write):
> > 
> >                                 if (timeout < 1)
> >                                         timeout = 1;
> >                                 timeout = 1;
> >                                 ret = chn_sleep(c, "pcmwr", timeout);
> > 
> > (notice that timeout is always 1).
> > 
> > If you feel adventurous, you can hardcode it to something like 30 and
> > see if a) message disappears b) you get normal sound. In my case (a)
> > happened and (b) did not -- I got distorted sound, but I was playing
> > with USB audio device, which has features not supported by the driver.
> 
> This has been discussed before on the list.  The statement immediately
> before the code fragment that you posted sets timeout to a dynamically
> determined value based on the buffer size and sample rate.  The 'if'
> block forces the timeout to be non-zero if the calculation results in a
> zero timeout.  Somewhere along the way, someone added the statement to
> unconditionally force timeout to 1, most likely to minimize the chance
> for skipping or distortion if a wakeup() was missed.  The will cause the
> 'while' loop to burn a bit more CPU time because it is essentially
> running in a polled mode.
> 
> The ich problem appears to be located in ich_intr().  This
> hardware-specific interrupt handler does not appear to be seeing the
> correct bits in the hardware registers that are supposed to tell it that
> an interrupt has occurred in the hardware play channel.
> 
> The "play interrupt timeout, channel dead" message will occur if there
> isn't at least one play channel interrupt per second.
> 
FWIW: I have received this message when dealing with USB audio (uaudio
driver). Increasing constant eliminated the message. I do not know
enough about audio handling to speculate any further.
---
Alexandre "Sunny" Kovalenko.