[vlc-devel] [PATCH] RFC: clock/aout: audio preroll discussion
remi at remlab.net
Tue Jun 19 21:38:58 CEST 2018
Le tiistaina 19. kesäkuuta 2018, 21.35.05 EEST Denis Charmet a écrit :
> > 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)?
Some plugins would probably be unable to implement such an interface.
> 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?
Yes. It substitutes block->i_pts, as that will soon contain the original PTS
instead of the intended playback time.
> <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
> </thinking out loud>
I don't understand.
> > 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
> >> 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 do not know why the playback time is determined ahead, other than that the
VLC design has always been that way.
A plain dumb audio player will start audio playback *without* a defined time,
and determine the actual play time from the audio clock. This avoids the
problem of inaccurate initial delay, and allows arbitrarily slow audio outputs
(AirPlay...). But it creates a whole lot of other problems.
> > 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?
I don't understand.
> Could we somehow write a generic corking wrapper which could be used in
> less evolved aout or is it too specific?
I don't know.
More information about the vlc-devel