VLC 2.0/2.0.1/2.0.2 audio stuttering/lag

[_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 ?

[Jean-Baptiste Kempf]

Probably not. Proper fixes will come to 2.1.0

[RadioMan57]

Also suffered from this problem since VLC 2.0 appeared.
Let me summarize my own experiences, described already in other threads:

- Asus mainboard P7P55, audio VIA VT1828S (listed in mainboard user manual)
- Win7 x64, VIA audio driver (from Asus website): stuttering every few seconds.
- Win8 x64, Microsoft audio drivers: VLC 2.0.x working fine.
- Win7 x64, Microsoft audio drivers: VLC 2.0.x working fine!

Here is how I got rid of the problem in Win7 x64:
- in device manager, uninstall your sound controller and choose the option to remove the driver files
- on reboot, controller will be identified and a generic Microsoft driver from Windows Update will be installed .

My conclusion:
The VIA audio drivers for VT1828S (maybe for other VIA chips as well) are causing the problems in VLC 2.0.x.

[Jean-Baptiste Kempf]

Do you have an ASUS EPU-Engine loaded?

[RadioMan57]

Not any more. I did use the ASUS EPU engine in the past, but think it's easier to define power & fan settings in BIOS.

[Solar Mike]

Hi Version 2.0.5 is also causing this issue, it started occurring several versions ago when using optical sound output. Previous versions prior to 2.xx were fine. I had hoped the latest update would fix the problem, but no.

No option now but remove the product and use something else, any recommendations?

[Rémi Denis-Courmont]

VLC 1.1.x.

[Resident]

same problem over here.
file + log > http://pastebin.com/y0VAT71X

[SSonik]

Tested VLC 2.1.0 on an affected machine - Issue exists in Windows (with EPU Engine active), but does not exist in Linux (Ubuntu 12.10). The CPU frequencies are still being adjusted on the fly, just not by the Asus utility.

Is this expected?

[MiGHTY_P1R4T3]

Hi everyone,
I managed to fix this problem.

I read it was caused by EPU 6 engine - and damn right it was. Having it on the normal "air-plane" mode didn't make VLC glitch, but other modes did. It's not only VLC this EPU 6 Engine affects, I've had problems with non-synced audio in some games.

Having it always on the normal mode, though, makes the CPU fan quite noisy. So, I went to my BIOS configs (my mobo is an Asus P6T SE), went to "Hardware Monitoring" (or similar, can't remember very well), and activated the "CPU Q Fan Control" and set it to "Standard". This manages the CPU fan speed automatically. I've noticed that now if my CPU usage is less than 20%, it's extremely silent, and when above (like, when gaming, video converting, etc) it gets a bit louder like the "normal air-plane mode" (needed to maintain the CPU cool). If you don't usually have an high CPU usage, you can set it to "Silent", and if it's summer and your pc tends to overheat, "Turbo" is always nice
Hope this fixes the problem for ya

//MiGHTY_P1R4T3

[SSonik]

Having it on the normal "air-plane" mode didn't make VLC glitch, but other modes did. It's not only VLC this EPU 6 Engine affects, I've had problems with non-synced audio in some games.

Having it always on the normal mode, though, makes the CPU fan quite noisy. So, I went to my BIOS configs (my mobo is an Asus P6T SE), went to "Hardware Monitoring" (or similar, can't remember very well), and activated the "CPU Q Fan Control" and set it to "Standard". This manages the CPU fan speed automatically.

If I'm reading this right, you still have normal/airplane mode enabled (CPU adaptive scaling is disabled). You've just allowed the CPU fan speed to ramp up and down depending on temperature.

The goal is adaptive CPU scaling enabled, and smooth VLC playback, at the same time.

[MiGHTY_P1R4T3]

The goal is adaptive CPU scaling enabled, and smooth VLC playback, at the same time.

You can't have both. It has to do with EPU's code, it's buggy, and I doubt ASUS cares about our dead mobos (not sure if it affects new mobos with newer versions of EPU, if it does, then they really have to fix it). As I said, this EPU also affects certain game's audio sync, by uninstalling it you fix 2 things at teh same time

But why do you want CPU scaling anyways? Really, now that I have no EPU at all, everything (even opening folders) is so much faster. If you intent to overclock/underclock, than having the clock constant in your BIOS is the only possibility.

//MiGHTY_P1R4T3

[Jean-Baptiste Kempf]

We will find a work-around for 2.1.0

[SSonik]

The goal is adaptive CPU scaling enabled, and smooth VLC playback, at the same time.

You can't have both.

Read up like one post before your first. Under Linux, CPU scaling works and VLC playback is smooth on the same affected hardware. I have no emotional attachment to the EPU engine software; if it is the cause of the problem under Windows, I'll remove it - I would like an alternative for CPU scaling though. If plain Windows power management works, then that's a good workaround.

But why do you want CPU scaling anyways? Really, now that I have no EPU at all, everything (even opening folders) is so much faster. If you intent to overclock/underclock, than having the clock constant in your BIOS is the only possibility.

Heat, idle power usage, fan noise, because the motherboard supports it, etc. Why do people always ask why something is needed when it causes a problem? Why is it always a sour grapes affair? Another place I saw this was with SChannel errors in the Windows event log; the "fix" was to disable SSL. That's not a fix. Then the follow up was "why do you need it". ffs.

[Rémi Denis-Courmont]

I can certainly agree that fixing the bug would be better than working around it by disabling power management. But there is strong sense that the bug actually lies in ASUS code for Windows. Consider that the same software on the same hardware but with a different OS or the same OS but different audio drivers appear to work just fine... None of the VLC developers, the video games developers or the SChannel developers can fix that. From our perspective, if the bug lies with ASUS EPU, the proper solution is to disable the EPU, or change hardware vendor.

It might be possible to solve the bug in VLC. But that will probably involve disabling power management automatically in software. So, it will still be a work-around, and it will still ruin power management.

[SSonik]

I've disabled EPU Engine now, and am allowing Windows to adjust CPU clock speed and voltage (FSB appears to not be dynamically adjusted though). There are still a few scattered debug messages regarding up-sampling and down-sampling, but audio/video timing (to the eye) is correct, also there's no stuttering or audio breaks anymore.