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

[Denis Charmet]

Hi,

I'm afraid my lack of knowledge/understanding of the aout might have 
spawned this thread. Let me ask you a few clarification so we can wrap 
our heads around that.

On 2018-06-19 19:37, Rémi Denis-Courmont wrote:
> 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.

Couldn't we separate the feeding of the buffer from it's playback state 
(in the limits of the buffer)?
Is it what corking does? If not could you explain it? I don't know 
really know how pulseaudio works...

Just to be sure the date field of Play is the date when the audio frame 
passed as parameter should be played?

<thinking out loud>
If so, if the time_get is inaccurate it could cause the buffer to 
underrun. Could we theoretically use that to somehow correct the TimeGet 
errors?
</thinking out loud>

> This is exactly what is already being done if TimeGet() succeeds 
> before
> playback starts.

I agree that if TimeGet is accurate it should work since the delay is 
applied before calling clock_update.

But I need to retry because some of my early tests using alsa showed 
crazy values which kinda spawned my concerns about timing the aout play 
thread. But I've made so many changes that it might end-up better than I 
expected.

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

Just to be sure, can you confirm that the playback time is determined 
ahead so we can start playing the audio after the dejitter delay or are 
there any more complex reasons?

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

So no "timing" notifications that we could use to call clock_update?

Could we somehow write a generic corking wrapper which could be used in 
less evolved aout or is it too specific?

Regards,
-- 
Denis Charmet - TypX
Le mauvais esprit est un art de vivre