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

[Thomas Guillem]

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