sound(4) vs alsa oss plugin

[Clemens Ladisch]

Andriy Gapon wrote:
> For some reason ALSA OSS plugin developers decided to use SNDCTL_DSP_GETOPTR and
> SNDCTL_DSP_GETIPTR to track state of playback/recording.

The reason might be compatibility with all the other OSS implementations
out there.

> Of all information returned by these ioctl they use just 'ptr' to track the
> progress by hardware.
>
> Now I see that under a "right mix" of circumstances the following is possible:
> - a buffer is completely empty for recording or completely full for playback
> - an application / ALSA checks the buffer pointer and gets some value P
> - the application sleeps for some time, perhaps oversleeps due to system load or
>   something else
> - the buffer is completely filled or drained depending on the direction
> - the application / ALSA checks the buffer pointer and gets the same value P
> - the application assumes that the buffer is in the old state and waits further
> - sound(4) code knows that the buffer is in the new state and does nothing
>
> So, couple of questions:
> - apparently this used to work (works?) in Linux - how?

What evidence do you have that this particular case is handled correctly
in Linux?  :o)

> - is there any trick that we can do in our sound(4) code to prevent this 'ptr'
>   full cycle from happening?

Not really.  It's the logic in the ALSA OSS plugin that should be fixed
to also use the 'bytes' field.

> Ideally, it's the logic in the ALSA OSS plugin that should be fixed, but...
> The upstream is not very responsive.

Not very active.  Patches will be accepted.  (As long as they don't
break with all the other OSS implementations ...)


Regards,
Clemens