SNDCTL_DSP_GETIPTR implementation

[Andriy Gapon]

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