[vlc-devel] [PATCH 0/8] asynchronous aout stream
thomas at gllm.fr
Sun Mar 10 09:10:46 CET 2019
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
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel