[vlc-devel] Endless buffer-way-too-late / audio, resampling loop
cs448 at cam.ac.uk
Tue May 29 16:42:12 CEST 2012
On 29/05/12 11:00, Rémi Denis-Courmant wrote:
> On Mon, 28 May 2012 18:31:34 +0100, Chris Smowton<cs448 at cam.ac.uk> wrote:
>> > Except tfor the mention of libmad of course. Then once dropping starts,
>> > we see an interesting pattern in which the 'resampling' events seem to
>> > make the situation worse (specific numbers made up):
> VLC upsamples when the audio output is late. If the decoder is on time,
> and only the output is late, that works, though it might cause pitch shift.
> If however the decoder is late also, then upsampling makes matters worse
> rather than better. That case is hopeless anyway.
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?
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
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?
> 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
caused terrible sound distortion using native PA. I've applied that
bug's suggested fix, and can now get reliable playback through the PA
More information about the vlc-devel