sound(4) vs alsa oss plugin
Andriy Gapon
avg at FreeBSD.org
Sat Jan 26 12:04:31 UTC 2013
on 26/01/2013 13:38 Clemens Ladisch said the following:
> 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.
Possible... Although opensound documentation has a big fat warning:
This ioctl call should only be used when using mmap(). In normal applications
it's practically useless.
>> 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)
No real evidence. Just an assumption that since it's done this way and hasn't
been changed in many years, then it must work (have been working when OSS was in
use) :-)
Also, given that ALSA comes from Linux, I assumed that ALSA OSS pluging was
developed and tested on Linux and thus primarily with Linux OSS implementation
in mind.
>> - 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.
OK.
>> 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 ...)
Great to hear. I will try to put together a patch.
Are you one of the ALSA developers? Should I contact you in addition to the
mailing list?
--
Andriy Gapon
More information about the freebsd-multimedia
mailing list