sound/pcm/* bugs (was: Re: page fault panic tracked down (selwakeuppri()) - really sound/pcm/*)

[Stefan Ehmann]

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.