[vlc-devel] [PATCH] MMDevice: fix crackling and libsync...

[Rémi Denis-Courmont]

On Thu, 28 Nov 2013 12:22:39 +0100, Jean-Baptiste Kempf <jb at videolan.org>
wrote:
> On 28 Nov, Rémi Denis-Courmont wrote :
>> On Thu, 28 Nov 2013 11:55:24 +0100, Jean-Baptiste Kempf
<jb at videolan.org>
>> wrote:
>> > ... by NULLifying the TimeGet function.
>> 
>> I don't know what libsync is, but this patch removes A/V synch
>> completely.
>> This is unacceptable.
> 
> Sorry, but A/V synch is now COMPLETELY off. By between 1 to 2 seconds.

If the computations are wrong, fix them. Removing them won't solve
anything.

> No to mention the huge crackling that happens in many cases
> 
> At least, with this patch, it is usable.

First, that cannot be true: there is no way to predict the offset between
video and audio without TimeSync, especially not with
WASAPI/PulseAudio-style APIs. It could be as long as 2 seconds. Second, the
commit log is essentially doing the exact opposite of what it says (aside
from the typo) and that is unacceptable anyway.

Plain audio may be usable. Video will be unusable.

> 
> I would say that the current behaviour in the source code is
unacceptable.
> 
>> AFAIR, VLC is not calling the clock in a tight loop. Unless the decoder
>> outputs ridiculously short packets, system calls will not be the
>> bottleneck. So that URL is mostly irrelevant. But even then, the patch
>> does
>> not correspond to the quoted solution.
> 
> Yet, now it outputs correct audio with all samples.

Of course it does. If you remove synchronization, VLC will just play audio
without resampling and plain audio playback will just work. That is to say,
so long as long term clock drift remains relevant, which should be long
enough to play music, possibly even a whole DVD.

But then video will be totally off. Otherwise why would we have bothered
to implement synchronization in the first place? We have already been
through this with PulseAudio not so long ago.

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