From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 04:16:55 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 05FD916A4CF for ; Sun, 18 Jan 2004 04:16:55 -0800 (PST) Received: from email06.aon.at (WARSL402PIP3.highway.telekom.at [195.3.96.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 1D90143D54 for ; Sun, 18 Jan 2004 04:16:32 -0800 (PST) (envelope-from shoesoft@gmx.net) Received: (qmail 119892 invoked from network); 18 Jan 2004 12:16:30 -0000 Received: from m105p024.dipool.highway.telekom.at (HELO ?62.46.3.24?) ([62.46.3.24]) (envelope-sender ) by qmail6rs.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 18 Jan 2004 12:16:30 -0000 From: Stefan Ehmann To: Don Lewis In-Reply-To: <200401180113.i0I1Dt7E052190@gw.catspoiler.org> References: <200401180113.i0I1Dt7E052190@gw.catspoiler.org> Content-Type: text/plain Message-Id: <1074428201.905.13.camel@shoeserv.freebsd> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 18 Jan 2004 13:16:41 +0100 Content-Transfer-Encoding: 7bit cc: current@FreeBSD.org Subject: Re: sound/pcm/* bugs (was: Re: page fault panic tracked down (selwakeuppri()) - really sound/pcm/*) 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: Sun, 18 Jan 2004 12:16:55 -0000 On Sun, 2004-01-18 at 02:13, Don Lewis wrote: > On 17 Jan, Stefan Ehmann wrote: > > Seems like some of my interpretation were wrong. > > > > The failing at the first try opening /dev/dsp seems to be related to the > > last point. If output is sent to esd by ogg123 (e.g) is terminated but > > sound is played for some more seconds. If the next file is opened the > > device is still busy. > > Try changing the two instances of > maxblksz = sndbuf_getblksz(b); > in chn_setblocksize() to > maxblksz = sndbuf_getsize(b) / blkcnt; > and change the condition for executing the sndbuf_remalloc() call from > if (sndbuf_getblksz(bs) != maxblksz) { > to > if (sndbuf_getblksz(bs) != maxblksz || sndbuf_getblkcnt(bs) != blkcnt) { > That fixed it. It doesn't stop as immediately as with non-esd (maybe half a second) but a quick test on my 4.9 system revealed that this seems to be normal. > It seems that the blkcnt for bufsoft never gets set in the non-vchan > case, and gets ignored in the vchan case because the call to > chn_setblocksize() that tries to set it passes 0 for the blksz > parameter. In either case the code in chn_setblocksize() that > calculates blkcnt and blksz from sndbuf_getbps(bs), sndbuf_getspd(bs)), > chn_targetirqrate, and CHN_2NDBUFMAXSIZE gets invoked, resulting in a > request for a CHN_2NDBUFMAXSIZE-size buffer and wierd values for blkcnt > and blksz. I typically see blkcnt getting set to 32. If you combine > this larger than expect blkcnt with the blksz from bufhard, which has a > much smaller blksz, bufsoft is likely to end up with a huge buffer. With > the above change, blkcnt will still be wierd, but its effects will be > papered over and bufsoft's size will get capped at CHN_2NDBUFMAXSIZE > (131072), so there should only be about 1.5 seconds of buffered audio. > > > Still have no clue why there are some non-used vchans busy. > > I haven't seen that here. > > > There is also now the issue of merging in phk's recent commit to the > sound code. I'll do some further testing to see if I can reproduce the the busy vchans issue and to find out if it really prevents panics.