Date: Tue, 26 Apr 2011 12:19:42 -0700 From: YongHyeon PYUN <pyunyh@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: Juergen Lock <nox@jelal.kn-bremen.de>, multimedia@freebsd.org Subject: Re: SNDCTL_DSP_GETIPTR implementation Message-ID: <20110426191942.GB9893@michelle.cdnetworks.com> In-Reply-To: <4DB701C4.30802@FreeBSD.org> References: <4DB6F7BA.4070808@FreeBSD.org> <4DB701C4.30802@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110426191942.GB9893>