[vlc-devel] [PATCH 0/8] asynchronous aout stream
thomas at gllm.fr
Sun Mar 10 09:11:32 CET 2019
On Sun, Mar 10, 2019, at 09:10, Thomas Guillem wrote:
> On Sat, Mar 9, 2019, at 19:09, Rémi Denis-Courmont wrote:
> > Le perjantaina 8. maaliskuuta 2019, 17.24.38 EET Thomas Guillem a écrit :
> > > Hello,
> > >
> > > This patch set should be applied on top of my clock branch:
> > > https://code.videolan.org/jbk/vlc/commits/clock-core/32
> > >
> > > All aout stream commands are now asynchronous.
> > >
> > > From an aout module point view, this mean that play/drain/flush/start/stop
> > > are always executed from the same thread.
> > This is not a promise that should be made. If/when audio decoder or filter get
> > threaded, it will not be reasonable to provide such guarantee any longer. It
> > wouldn't be the first or even the second time that we shoot ourselves in the
> > feet with that silly API guarantee.
> OK but these calls need to be protected with a mutex. It is possible
> now to call flush and play from 2 threads without a protection.
> > Besides, it is *useless*. We want low-latency for user controls and
> > sometimes also for playback. Running everything in a single thread avoids
> > blocking during function calls from the decoder/filter or the GUI. But it does
> > not help at all with low latency. In fact, it even increases those latencies.
> > And lastly, this breaks flow control.
> > If you don't want Play to block, you need to implement it that way in the
> > individual plugins. You cannot cheat your way out of that with core changes.
> > However, again, this will break flow control, so it does not seem like a good
> > idea anyhow.
> It's quite easy to make the play not blocking. Modules should be able
> to return the same block with an offsert change, corresponding to data
> to written.
> > And if you don't want Flush to block, then you actually need to change the
> > plugin API so that we know when the buffers are drained/flushed. You cannot
> > cheat your way out if it either
> I'm not sure that all audio API provide a way to have a
> async/nonblocking drain. I will check tomorrow.
> > So this seems not just useless, but actually harmful to me.
> > -1 from my behalf.
> > --
> > Rémi Denis-Courmont
> > http://www.remlab.net/
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel