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

Rémi Denis-Courmont remi at remlab.net
Tue Jun 19 19:37:45 CEST 2018

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 time
> (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.

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 can 
support this.

> The problem is that the first play often need to be played in the future.

That's not a problem: you can always defer audio, if you know how long.
The opposite would be a problem.

> There is often a 30/50ms pts delay (tested on current master). With the
> 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 other
> modules will fail to start at this given time.

If the audio output makes up a poor latency estimate, then this happens. 
That's why PulseAudio does corking instead. If you remove the corking and 
timer from PulseAudio, PulseAudio will simply exhibit the same problem.

> 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 before 
playback starts.

>  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 all
> 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 API.

I prefer solution 2 and the proper API is what we have right now.


More information about the vlc-devel mailing list