[vlc-devel] Endless buffer-way-too-late / audio, resampling loop

[Rémi Denis-Courmont]

Le mardi 29 mai 2012 17:42:12 Chris Smowton, vous avez écrit :
> I understand the output-late case you're trying to fix -- I guess this
> is for an output with a slightly slow crystal which would otherwise
> cause drift w.r.t. the video?

That's one potential cause, yes.

> However I'm not sure I understand the "decoder is late also" case --
> firstly, given that I was playing a file with no video, and so nothing
> to synchronise against, what does it even mean for the decoder to be
> late? Certainly it's late with respect to the arbitrary timescale VLC is
> trying to make it conform to, but in this case surely the right thing to
> do would be to reset the scale with respect to the buffer we're about to
> play?

VLC assumes that the cumulated latency decoding, filtering, output of the 
audio track is less than a certain caching value (--file-caching and the 
likes). The default duration is 300ms or 1000ms depending on the source. 
Unfortunately, audio outputs exhibit very long latency, such that the total 
can exceed 300ms, and then there is simply no way to ever get in synch.

This is a historical bug in the VLC design.

For instance, PulseAudio has a very high latency to reduce processor wakeups, 
unless a short "tlength" is forced in the buffering parameters.

> Secondly, supposing there was video, then do I understand correctly that
> the "buffer way too late" messages are throwing away audio that's being
> delivered too late for the video, hoping that this will lead to the
> codec catching up with the video? If so, why does the date_Move call get
> made only *after* we've nearly caught up? Then when it is made, why does
> it harm the situation? I guess I don't understand why this loop of
> repeated failure is inevitable when one could just seek both streams to
> a good point, allow both to fill their buffers and then resume playback?

I don't remember the exact details, but if you land with a "stable" latency of 
1.5 seconds, then you obviously broke synchronization. VLC tries to keep 
within -40ms/+60ms as recommended by the EBU.

> > With ALSA, this problem is known to occur when using the PulseAudio ALSA
> > plugin. The native PulseAudio output should be used instead. Maybe it
> > also happens with other ALSA output plugins or drivers. In that case,
> > I'd suggest you stash your hacks away, replace '#if 1' at
> > modules/audio_output/alsa.c:448 with '#if 0' and recompile. Hopefully
> > that works around the problem.
> 
> This is correct -- I was using the ALSA->PA bridge in order to work
> around bug
> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/751265 which
> caused terrible sound distortion using native PA. I've applied that
> bug's suggested fix, and can now get reliable playback through the PA
> output driver.

I find it dubious that ALSA->PA would work and direct PA wouldn't, with the 
same PulseAudio daemon and the same hardware.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis