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

[Rémi Denis-Courmont]

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.

To fix this, increase the caching value; sadly, this cannot currently be
fixed automatically.

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.

> msg_Warn (aout, "not synchronized (%"PRId64" us), resampling",
>                    delta);
> /*
>          if (date_Get (&owner->sync.date) != VLC_TS_INVALID)
>              date_Move (&owner->sync.date, delta);
> */
> 
> This indeed fixed playback! Now my logs look like this (real numbers 
> this time -- I fabricated the ones earlier because I don't have the time

> to rebuild without my hack right now):

That might "work" as far as sound continuity is concerned. But in general,
it breaks A/V sync.

-- 
Rémi Denis-Courmont
Sent from my collocated server