Date: Sun, 18 Jan 2004 13:16:41 +0100 From: Stefan Ehmann <shoesoft@gmx.net> To: Don Lewis <truckman@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: sound/pcm/* bugs (was: Re: page fault panic tracked down (selwakeuppri()) - really sound/pcm/*) Message-ID: <1074428201.905.13.camel@shoeserv.freebsd> In-Reply-To: <200401180113.i0I1Dt7E052190@gw.catspoiler.org> References: <200401180113.i0I1Dt7E052190@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1074428201.905.13.camel>