Date: Wed, 27 Apr 2011 09:46:51 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: pyunyh@gmail.com Cc: multimedia@FreeBSD.org Subject: Re: SNDCTL_DSP_GETIPTR implementation Message-ID: <4DB7BBDB.8070300@FreeBSD.org> In-Reply-To: <20110426191942.GB9893@michelle.cdnetworks.com> References: <4DB6F7BA.4070808@FreeBSD.org> <4DB701C4.30802@FreeBSD.org> <20110426191942.GB9893@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 26/04/2011 22:19 YongHyeon PYUN said the following: > 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. I don't think that this would be of any help to what I am trying to fix. But admittedly I am not much of an expert in OSS programming, neither on driver side nor on userland side. What I see is this. Many Linux(-ish) OSS applications, including ALSA OSS plugin, use SNDCTL_DSP_GETIPTR to check if any recorded samples become available. I've verified in the source code that ALSA OSS plugin only looks at ptr value, it completely ignores other returned parameters. So, right now our driver points the ptr to the start of the recorded data. Which means that the ptr doesn't change when new recorded data becomes available, it only changes when application reads some data from the buffer. But the applications that I am speaking about expect the opposite behavior - they expect that the ptr points to the end of recorded data and that that changes when more data becomes available in the buffer. The proposed patch should change our behavior to match their expectations. And the OSS specification seems to support their expectations too. How they deal with buffer sizes, wraparounds, etc, that I haven't verified. But I am pretty sure that they do it in a reasonable fashion and our driver is compatible with what they are doing. I am basing my assessment on the fact that with the proposed change I can record through Linux ALSA OSS plugin (in Skype) perfectly well. So, thank you for valuable insights into the code, but it seems that they are not directly applicable to this particular problem. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DB7BBDB.8070300>