VLC 2.0/2.0.1/2.0.2 audio stuttering/lag

[RipTide]

Hello people,

I'm no expert in these things but I think I 'might have' found the actual source of audio stutter.
I got a fresh copy of Windows 7 ultimate 32-bit installed some weeks ago, and then installed VLC 2.0.1 too along with many other applications and drivers.
It worked fine for sometime but after that the audio started stuttering every 5 seconds or so, and that happened with any kind of media file.

This is similar to the error many people have reported here, and hence I read the whole thread discussions but wasn't able to find any effective fix.

While going through the list of applications installed on my system (while looking for any unwanted installation), I saw I had installed 'K-lite codec pack 880 mega', so I uninstalled it and the stutter disappeared on VLC!! It was TOTALLY hit-and-trial and I'll leave it to the technical experts to make some meaning of it.

It may or may not be the solution for everyone I couldn't know, but it indeed worked for me!

[Jean-Baptiste Kempf]

This is quite weird, to be honest.

[DanteElysium]

Hello !

I've just installed the 2.0.4 32bits and the problem is still here...
I've also tested the 2.0.2 64bits but it's the same problem...

I still have to manually change the mode of my CPU to "normal" to make it work. but in this mode, the fans are very noisy...

Bye

[chid]

It's amazing how irritating this bug is, it's difficult to describe how it affects the listening experience.

It seems to affect 32-bit 2.0.3 running on a 64bit OS.
I have switched to the 2.0.4 experimental branch Twoflower, compiled Oct 18th for 64bit

It plays gapless =)

http://download.videolan.org/pub/videol ... ast/win64/

Hope it works well for you too

Charley

[DanteElysium]

Hello,

I just Tried the 2.0.4 64bits but the problem is still here...

Bye

[Rémi Denis-Courmont]

Of course it's still there. Nobody came up with a solution that I could see.

[user957]

Look.

The whole purpose of VLC is that it is compatible with the most popular OSs. So regardless of your semantic discussions, we have encountered a fatal flaw in VLC. Now, most people (ie users of VLC) would not lift a finger to fix or help with these (so called leechers), so what do you reckon they will do? They'll download another player or revert to past versions of VLC. This of course negates, to an extent, the purpose of the hard work that the team puts into the development of the program.

My two cents are- just treat this as any other bug. The team are obviously extremely competent and does not need fruitless sematic arguing to fix the bug.

Anyway, good luck. I'll revert to 1.1 until further notice. VLC is STILL the best player at that version.

[Rémi Denis-Courmont]

The point is, the team does not need constant reminders of unfixed bugs... By the way, it is being treated like a normal bug. Like other bugs that are not understood, it is not being fixed. If that means a large slice of the user base stops upgrading or switches to the competition, so be it.

At this point, I guess the bug will remain for some time. Without conclusive analysis from someone able to reproduce it (none of the developers could so far that I'd know), there is little to no hope that a developer would (be able to) fix it. I have begged for a code base bissection of the regression for several months. Nobody cared to provide one. I spent hours adding coinfigurable clock sources, only one user bothered to try it out and report. There really is not much I, or the rest of the team, can do.

Maybe a developer will rework something in the audio decoding, filtering or output that will hide or remove the bug, but that would be accidental. That is not a possibility to be relied upon.

[user957]

All right, so tell me what information you need and I will do what I can to provide it. I'm not a pro in any way, but as a normal user I'll see what I can do. I can record a video of the problem if you want.

[serianox]

I am the creator of the thread, i've completely forgotten about this thread and now i see a lot of feedback on this bug and it makes me very happy. Thanks for your work devs. My motherboard comes with a software that underclocks/overclocks automaticaly the processor, disabling it completely solves the problem, so it must me a clock issue. however cores get hotter now. it would be nice to have this bug solved in a future vlc release. I can help you with whatever you need to test, just tell me, i'm a regular user though so take that in mind.
Thanks again for your work, and sorry if i typed something wrong i'm from Argentina

[serianox]

• Get a VLC nightly build from September 7th 2012 or later, or compile VLC 2.1.0 manually from git.
• Start VLC.
• Open the preferences.
• Select All then Advanced.
• Change the Clock source.
• Save and exit.
• Start VLC and play something.

Reiterate until you find a clock that does not break your audio output... if any

Did this with last build avariable VLC 2.1.0-git-20121106-0004 Rincewind
the problem is still there, no matter what clock source i choose i still get the stuttering, however it is less intense than the 2.0.x
is i have mentioned before, the problem solves if i remove the downclock of the processor
Thanks

pd: i did not try the System time (DANGEROUS!) clock source. should i?

[Rémi Denis-Courmont]

It won't harm your computer. It's just known to not work properly in ways unrelated to stuttering.

[_Rock_]

Hi everyone

im using vlc aswell in i got the same problem since 2.0 (now im using 2.0.4).
My hard-/software specs:
- Asus P6T Maiboard (with onboard Raltek HDA soundcard) and with EPU6-Engine
- NVidia Geforce 9700GTX with HDMI-Out (which I sometimes use as Audio-Out)
- Win7 x64

Like the others said, as long as I keep the power-saving of the EPU-Engine at Performance, there is no audio-lag, as soon as i put it to Power save, there are these annoying audio gaps.

By playing around with the clock settings I've found some way of setting which mostly kills these gaps. (Actually I didn't find the "Clock source"-Setting as mentioned above, but some other Clock-related settings)
My settings are set this way:

Code: Select all

Clock reference average Counter: 4 (Default: "40") Clock synchronisation: Enable (Default: "Default") Clock Jitter: 5000 (left at default)

using this settings, there are some gaps at the start of a audio-stream (for like the first 3-10secs), but then it keeps working!
Looking at the messages (first 5secs:)

Code: Select all

main warning: buffer way too late (265353), dropping buffer main warning: buffer way too late (218913), dropping buffer main warning: buffer way too late (258983), dropping buffer main warning: buffer way too late (238613), dropping buffer main warning: not synchronized (-40807 us), resampling main warning: audio output out of sync, adjusting dates (-40398 us) main warning: not synchronized (-40397 us), resampling

After these 5 Secs there are always these messages appearing (about every second):

Code: Select all

main warning: audio output out of sync, adjusting dates (-43580 us) main warning: not synchronized (-43579 us), resampling

But as mentioned before, no gaps anymore!

BUT I just found out, this only works for audio-Files. Using Video-Files with theses Settings just fails epic. The Videopicture mostly freezes and the audio is just beeing played like in 2x-mode. Also VLC is veeery unresponsive. Looking at messages theres a HUGE spam of following:

Code: Select all

main warning: buffer way too late (420093), dropping buffer main warning: buffer way too late (398759), dropping buffer main warning: buffer way too late (377426), dropping buffer

So as I interpret, this way of clock-setting only works for Streams with low bit-rates. At high bit-Rates/video, enabling clock-sync seems to be a bad idea...
I hope my information can somehow help to find that bug and somehow solve it!

If I can help with any more Information, just ask, Ill try to answer as good as possible.

[Rémi Denis-Courmont]

This just confirms the general suspicion that the problem is caused by a bogus real-time clock in ASUS devices rather a VLC bug. In fact, the bug tracker shows VLC 1.1.x already had the same problem albeit apparently more rarely than VLC 2.0.x.

Unfortunately, that does not really help solving the problem...

[Jean-Baptiste Kempf]

im using vlc aswell in i got the same problem since 2.0 (now im using 2.0.4).
My hard-/software specs:
- Asus P6T Maiboard (with onboard Raltek HDA soundcard) and with EPU6-Engine
- NVidia Geforce 9700GTX with HDMI-Out (which I sometimes use as Audio-Out)
- Win7 x64

Like the others said, as long as I keep the power-saving of the EPU-Engine at Performance, there is no audio-lag, as soon as i put it to Power save, there are these annoying audio gaps.

THanks a lot for the report.

What are you playing?

[_Rock_]

This just confirms the general suspicion that the problem is caused by a bogus real-time clock in ASUS devices rather a VLC bug. In fact, the bug tracker shows VLC 1.1.x already had the same problem albeit apparently more rarely than VLC 2.0.x.

Unfortunately, that does not really help solving the problem...

but its only a problem which only occurs in vlc. Any other player (Windows media player, quicktime, powerdvd, windows media player classic etc.) doesn't have this problem. So where's the difference how vlc plays a stream to all other players then?

Also:

[...]
I have been disabling the power management settings in the bios on a HP 6000 pro SFF PC that had the issue with all 2.x.x players. Now after setting everything back to how they were, videos play smooth.
[...]
I do remember seeing something about the linux cpufreq still being broken with Core2 Duo and newer CPU's. Coincidence?

according to this post, the problem doen'st exist only on asus motherboards. So even if its a failure of Power-saving chipsets, it seems to be present on different hardware and bothers plenty of users. I understand that its very hard to find a solution for a bug which appears only on specific hardware and thats why i'm trying to help...

THanks a lot for the report.

What are you playing?

well for the testing i was using a 40kb aac+-Stream and sadly i had to realize that this seems to be the highest non-gapping-bit-rate. Playing some 96kb-Stuff already has the gaps even with my new clock-settings

[Rémi Denis-Courmont]

This just confirms the general suspicion that the problem is caused by a bogus real-time clock in ASUS devices rather a VLC bug. In fact, the bug tracker shows VLC 1.1.x already had the same problem albeit apparently more rarely than VLC 2.0.x.

Unfortunately, that does not really help solving the problem...

but its only a problem which only occurs in vlc. Any other player (Windows media player, quicktime, powerdvd, windows media player classic etc.) doesn't have this problem. So where's the difference how vlc plays a stream to all other players then?

To find out why it happens more often in 2.0 versions than ealier ones, a source code bissection would be required. But that is a painfully slow and tedious experiment, especially on Windows. Currently the cross-set of developers able to compile VLC and users able to reproduce the problem is empty, so nobody really knows. I would hazard to guess that it is the funky indirect side effect of one of the several major input and audio changes in VLC 2.0 (e.g. new resamplers, audio buffers enlargement, decoder buffer loss fix...).

The difference between VLC and the other players is most probably the clock source. VLC uses the computer/system time while most media players use the audio hardware time. VLC has always been like that, and it has always caused problems with some broken hardware. But this approach also has a number of advantages and broken computer clock was not really a design criteria when VLC was invented. Regardless, nobody has stepped up to even try to implement audio-based clock inside VLC, so which clock is best in which circumstances is rather moot a topic. The point is, just because a bug only affects VLC does not automatically imply that the bug is in VLC.

I guess, unfortunately, that some vendors take some ungranted freedoms with their clock implementation to improve uptime on battery. VLC does explicitly require a precision of 5 milliseconds at startup on Windows. But either the vendors have probably figured out that they would get much greater savings if they ignored software requirements.

[_Rock_]

thank you for your detailed answer!

So in other words, there seems to be no way to solve this unless using another clock, which you mentionend never was an option for vlc.
I just wonder, if it really was the vendors which made such a dirty implementation of the clock just for powersaving, wouldn't there be other software affected aswell?
Or do we just recognize the problem in VLC because a streaming-software is very sensitive to its clock?

[Rémi Denis-Courmont]

How else would you explain that the problem essentially vanishes in performance (yet not over-clocked) settings? Also, what would be the point to decrease clock precision in other settings, except for saving energy?

[Jean-Baptiste Kempf]

well for the testing i was using a 40kb aac+-Stream and sadly i had to realize that this seems to be the highest non-gapping-bit-rate. Playing some 96kb-Stuff already has the gaps even with my new clock-settings

Can you share one of your test files, that actually drops audio?

Can you come on IRC, to do some testing, if you have the courage?

[Fandabu]

I don't know if it helps, but I experience the same issues described (stuttering every ~2s!) with audio output set to "waveout". By selecting DirectX the issues are completely gone.
Also no debug messages appear in directx mode. In waveout mode many out-of-sync messages appear.
The CPU load is nearly the same.


Win 7 64bit
VLC 2.0.4 32-bit
Realtek chipset

[Jean-Baptiste Kempf]

OK. I can now reproduce the issue.

[flemmingbjerke]

Though this is a windows forrum and I use linux (debian testing), I think it is of some interest that I have the same problem with vlc-2.0.3

Code: Select all

main audio output warning: resampling stopped after 1230566 usec (drift: 2182) main audio output warning: not synchronized (62052 us), resampling main audio output warning: PTS is out of range (-29948), dropping buffer main audio output warning: buffer too early (-44621), down-sampling main audio output warning: not synchronized (66001 us), resampling

It seems correct that some clock misadaption causes the problem, because if I use Jack which takes over the sound system and sets the clock for sound, the problem disappears. On the condition that I don't set the latency too low (23 msec works fine, Frames/Period=512, Periods/Buffer=2). If I reduces Frame to 256 (and latency to 12 msec), the problems start, but they are not frequent.

It does not seem to have anything to do with ASUS: My PC has an IBM motherboard with Intel(R) Pentium(R) 4 CPU 2.80GHz. The sound card is a Maudio 2496. Rather it seems to be cross-platform issue.

[Rémi Denis-Courmont]

I doubt it is not a cross-platform issue. They are just different root causes leading to the same symptom of broken audio synchronization. The ALSA plugin has some synchronization issues, mostly when using it on top of PulseAudio and/or when resuming from pause.

[passport]

Has this been fixed in 2.05 ?