[MPlayer-dev-eng] [PATCH] Add audio support for sndio API.

[Reimar Döffinger]

On 20.12.2013, at 09:13, Alexandre Ratchov <alex at caoua.org> wrote:
> On Fri, Dec 20, 2013 at 08:30:20AM +0100, Reimar Döffinger wrote:
>> On 20.12.2013, at 01:36, Alexandre Ratchov <alex at caoua.org> wrote:
>>> On Thu, Dec 19, 2013 at 01:32:05PM +0100, Reimar Döffinger wrote:
>>>> Alexandre Ratchov <alex at caoua.org> wrote:
>>>>> On Thu, Dec 19, 2013 at 11:25:25AM +0100, Reimar Döffinger wrote:
>>>>>> Alexandre Ratchov <alex at caoua.org> wrote:
>>>>>> Sorry, but this makes 0 sense to me. Delay is something you
>>>>>> calculate yourself in e.g. movcb, you don't get it from sndio, so
>>>>>> I don't understand how what sndio does helps you.
>>>>> 
>>>>> During playback, the delay is defined as:
>>>>> 
>>>>> delay = (samples_written - samples_played) / sample_rate
>>>>> 
>>>>> where samples_played is the sum of "deltas" reported by the
>>>>> onmove() call-back.
>>>>> 
>>>>> It can't be negative (sndio pauses when the buffer is empty)
>>>> 
>>>> It can still become negative if you end up updating delay in a
>>>> way that makes it mismatch the actual buffer fill. You set it to
>>>> 0, which would only be correct if reset discarded the buffers,
>>>> but previously we said it doesn't. The documentation as usual
>>>> doesn't document the behaviour at all, so I can't know what it
>>>> does.
>>>> 
>>>>>> Also, since reset does not drop the buffers I can't see how it
>>>>>> should be correct to set delay to 0, any new data should be
>>>>>> delayed by as much time as there is data the old buffers.
>>>>>> 
>>>>> 
>>>>> When we call sio_start() to resume, we consider buffers are drained
>>>>> (thus empty)
>>>> 
>>>> You can't just "consider" them empty when they aren't.
>>>> Either reset discards the buffers or it does not. You said it
>>>> doesn't, so the buffers are not empty after reset and setting
>>>> delay to 0 is wrong (since delay 0 should mean the buffers are
>>>> empty).
>>> 
>>> according to the man page "The sio_stop() function stops playback
>>> and recording and puts the audio subsystem in the same state as
>>> after sio_open() is called."
>>> 
>>> So the "contract" is: after sio_stop() returns, the device can be
>>> used as if it was freshly opened & configured (implies empty
>>> buffer).
>> 
>> So it does discard buffers? You were telling me the opposite before.
>> Or does it block and not return until everything was played?
> 
> I've never said it discards buffers. After sio_stop() returns, the
> device is in the same state as before sio_start() was called, which
> implies buffers are empty.
> 
> FYI, few years ago, the implementation used to copy the buffer,
> return immedately then play the copy in the background.

If that is a valid implementation of the API then the close function is broken instead.
It must wait until the data has been played, otherwise we'd end up playing consecutive files over each other.