From owner-freebsd-current@FreeBSD.ORG Wed Sep 8 02:57:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 820A016A4CE for ; Wed, 8 Sep 2004 02:57:41 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19DA043D1F for ; Wed, 8 Sep 2004 02:57:41 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i882vXnB040143; Tue, 7 Sep 2004 19:57:37 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409080257.i882vXnB040143@gw.catspoiler.org> Date: Tue, 7 Sep 2004 19:57:33 -0700 (PDT) From: Don Lewis To: Alex.Kovalenko@verizon.net In-Reply-To: <1094609440.673.25.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: pcm0:play:0: play interrupt timeout, channel dead X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 02:57:41 -0000 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: 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.