The VideoLAN Forums

Hi,

I often (ok, actually more feels like usually) experience unpleasent timing issues in VLC that lead to jumpy/stuttering (muted for fractions of seconds in regular intervalls) audio playback in both audio only and audio/video files, no mattter the file format. Except for slight differences in the exact patterns of the disruptions or their length, this happens in Windows and Linux and on different PCs.
This usually happens when playback just started or is resumed and most of the time just lasts for ~4 seconds. Also on all tested systems, the playback of a file usually stops up to 3 secs too early before the end of file.
There are various messages in the debug log ranging from the usual PTS related stuff like "main warning: output date isn't PTS date, requesting resampling" or "main warning: PTS is out of range" to "pulse debug: underflow" (on Ubuntu).

I kind of gave up hope to get *the* answer that can sort out all these problems for me and some occasions of these problems are also definitely caused by poor onboard sound hardware, but for the other cases where VLC is the only program having trouble with audio playback, I'm wondering: Is it just me or what is the problem with VLCs timing and audio syncing mechanisms?
Maybe I'm a bit naive, but can it really be that hard to just shove rendered audio data to sound hardware in time? At least I don't know any other media players with such blatant flaws in audio playback...

Historically, VLC was designed as a live streaming client. For this scenario, audio resynchronization is unavoidable as the source (e.g. IPTV broadcaster) to speed up or down to please your sound card clock. This is kinda counterproductive for local files though but this is not exactly trivial to fix... and nobody stepped up to to revamp the VLC input clock, or to sponsor someone to do so.

Some form of lip synchronization is needed in any case. While your digital TV decoder can be tuned precisely to the known latencies of the hardware, VLC has to run on virtually infinitely many hardware configurations. So it's probably forever going to somewhat flaky at the very start (or upon resuming from pause). But the situation could certainly be improved a lot still with qualified and available developers.

Thanks for your reply.
I kind of guessed that this timing system has its origin in VLCs streaming past...
At least I'm releaved to see it's apparently known with the developers that it still "could be improved a lot", especially with local files. So there is still hope these problems are fixed at some point. Until then you probably just have to deal with the fact that VLC can't effectively be used to play short clips that start or end abrupt. I'd certainly love to help improve this situation, but unfortunatelly I'm currently a bit short on ressources (namely time and money), too...