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

[Chris Smowton]

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 
play?

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 
around bug 
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/751265which 
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.

C