[vlc-devel] [PATCH 0/8] asynchronous aout stream

[Thomas Guillem]

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. 

*not 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:
> https://mailman.videolan.org/listinfo/vlc-devel