SNDCTL_DSP_GETIPTR implementation

[YongHyeon PYUN]

On Tue, Apr 26, 2011 at 08:32:52PM +0300, Andriy Gapon wrote:
> on 26/04/2011 19:50 Andriy Gapon said the following:
> > 
> > Guys,
> > 
> > I reading this http://manuals.opensound.com/developer/SNDCTL_DSP_GETOPTR.html
> > It says: "In mmap mode (only) the ptr field tells the location where the next
> > sample will be recorded."
> > In my opinion that means that we have a mistake in our code and the following
> > patch should be applied.  But I am not sufficiently familiar with this code.
> 
> It seems that with this change linux alsa lib with oss plugin works for audio
> recording now.  E.g. in skype.
> Hope I wasn't sloppy with my testing again, so I will re-test.
> 
> Juergen,
> will you be able to test this too?
> 
> > --- a/sys/dev/sound/pcm/dsp.c
> > +++ b/sys/dev/sound/pcm/dsp.c
> > @@ -1655,7 +1655,7 @@ dsp_ioctl
> >  				/* XXX abusive DMA update: chn_rdupdate(rdch); */
> >  	        		a->bytes = sndbuf_gettotal(bs);
> >  	        		a->blocks = sndbuf_getblocks(bs) - rdch->blocks;
> > -	        		a->ptr = sndbuf_getreadyptr(bs);
> > +	        		a->ptr = sndbuf_getfreeptr(bs);
> >  				rdch->blocks = sndbuf_getblocks(bs);
> >  				CHN_UNLOCK(rdch);

It had been long time ago since I read sound code so I'm not sure
my understanding is correct or not. I think our implementation
slightly violates OSS API. bytes of count_info for both
SNDCTL_DSP_GETOPTR and SNDCTL_DSP_GETIPTR is number of
bytes played/recorded so far but our code always returns a fragment
size. However I think it returns correct ptr value in the fragment.
I think applications should not rely on SNDCTL_DSP_GETOPTR or
SNDCTL_DSP_GETIPTR since byte can reset to 0 after long running of
playing/recording. SNDCTL_DSP_GETOPTR/SNDCTL_DSP_GETIPTR
and SNDCTL_DSP_GETODELAY/SNDCTL_DSP_GETOSPACE are normally used to
track overrun condition so old sound code tried to return accurate
ptr to application by triggering DMA. However this was disabled
long time ago because it can cause unnecessary delays so
application can get same ptr in successive ioctls which in turn may
make application think playback/recording is not working. This may
happen on applications that try to respond smarter and have complex
buffering strategies.
How about reviving chn_rdupdate() in SNDCTL_DSP_GETIPTR? This may
introduce additional latencies but you may be able to know the root
of the issue.

> >  	    		} else
> > 
> > P.S. leading (indenting) whitespace in this file is a mess.
> 

Agreed.