[vlc-devel] [PATCH] RFC: clock/aout: audio preroll discussion

Rémi Denis-Courmont remi at remlab.net
Thu Jun 21 09:13:19 CEST 2018

I don't see how adding a dejitter delay changes anything. The intended play time (date) will be further away, and the core will prepend more zeroes. It's transparent.

Le 20 juin 2018 17:23:20 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>On Tue, Jun 19, 2018, at 19:37, Rémi Denis-Courmont wrote:
>> Le tiistaina 19. kesäkuuta 2018, 18.09.32 EEST Thomas Guillem a écrit
>> > Currently, only the pulse audio module is able to start at a given
>> > (because the API allows to start a stream corked). Every other
>modules will
>> > start right after the VLC Start callback.
>> Err no. Start() does not have any audio data. Most audio outputs
>start on the 
>> first Play(). And that first Play() actually conveys zero padding
>generated by 
>> the core to time the playback correctly.
>I didn't know that. Good to know.
>> The problem is that this does not generally work well. It requires
>that the 
>> latency is known correctly up-front. Not all audio drivers/hardware
>> support this.
>> > The problem is that the first play often need to be played in the
>> That's not a problem: you can always defer audio, if you know how
>> The opposite would be a problem.
>> > There is often a 30/50ms pts delay (tested on current master). With
>> > future output clock, this delay should be arround the dejitter
>value of the
>> > vlc_clock_t (200 or 500ms). No problem for pulse audio, but every
>> > modules will fail to start at this given time.
>> If the audio output makes up a poor latency estimate, then this
>> That's why PulseAudio does corking instead. If you remove the corking
>> timer from PulseAudio, PulseAudio will simply exhibit the same
>> > We have some choices:
>> > 
>> >  1/ Simplify the date handling of aout modules: all modules behave
>the same
>> >  way, and the core handle the delay (by playing silence when
>needed). So we
>> >  move the delayed start functionally from PulseAudio to the core:
>this is
>> > what this patch is doing.
>> This is exactly what is already being done if TimeGet() succeeds
>> playback starts.
>So if I understand correctly: for pulseaudio, TimeGet() will fail
>before playback starts (because the uncork is delayed), but it's OK
>since this module handle the deferred start itself. 
>For other modules, they should return a valid TimeGet() before playback
>is started in order to play some silence that will correspond to the
>audio device hw delay. Right ?
>But how do you handle, in the future clock branch, a first play that is
>deferred by the clock dejitter time (200-500ms) ?
>The core need to play some silence somehow, or should every module
>handle it themselves ?
>> >  2/ Modify the aout API to handle 2 type of aout modules: one like
>> > pulseaudio (that handle a play date), and all the others one.
>> And this is the only way to get things working somewhat properly
>within the 
>> current system, where the playback time is determined ahead.
>> > I prefer the solution 1/ since it'll ease future debugging because
>> > modules will behave the same way.
>> In other words, you want to keep the core as it is and rip out some
>code from 
>> PulseAudio. End result: PulseAudio will work worse and the other
>outputs will 
>> be exactly as broken as before.
>> Well no thanks.
>> > If you prefer the solution 2/, we need to think about a proper aout
>> I prefer solution 2 and the proper API is what we have right now.
>> -- 
>> 雷米‧德尼-库尔蒙
>> 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:

Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20180621/06556ec1/attachment.html>

More information about the vlc-devel mailing list