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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Tue Dec 31 16:39:21 CET 2013

On Fri, Dec 27, 2013 at 12:47:55AM +0100, Alexandre Ratchov wrote:
> On Tue, Dec 24, 2013 at 10:01:21AM +0100, Reimar Döffinger wrote:
> > On 20.12.2013, at 12:09, Alexandre Ratchov <alex at caoua.org> wrote:
> > > On Fri, Dec 20, 2013 at 12:06:38PM +0100, Reimar Döffinger wrote:
> > >> 
> > >> 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.
> > > 
> > > sure; and this has been fixed few years ago.
> > 
> > You mean when the close() behaviour changed to wait?
> Yes.
> > I understood what you said like this: the previous behaviour was
> > valid and correct as well, and it might be possible it might be
> > changed "back" again (at least to something similar to the old
> > behaviour).
> That would be a regression, as this would produce the artefact you
> described (quick start/stop cycles play over each other, which is a
> bug).
> > In that case our close function should ideally try to deal with
> > such a behaviour.
> Ideally we shouldn't depend on how long sio_stop() or other
> functions take to return. Assuming no samples will be lost and that
> streams won't play over each over is safe.

Well, the problem is there aren't many ways to guarantee these two.
Also, we in fact assume one more thing: That when you write a sufficient
amount of data right after sio_open() it will basically be played
instantaneously (because any delay there we will not take into account
and thus will directly cause desync).
As far as I can tell, this basically leaves only sio_open or sio_stop/sio_close
waiting as a possible solution...
If that is the case, it would be much nicer if the documentation just
said so clearly.

> > I'll take a last look hopefully soon, but I think it's time to
> > commit what we have now.
> Excellent!

Committed, with a few cosmetic changes that I hope were ok to add
without asking for review first.

More information about the MPlayer-dev-eng mailing list