The VideoLAN Forums

Hi,

if I play a mp3 from file or stream, changing the volume is notchy. There is a delay of several seconds (up to 30+) during adjusting the volume and the actual volume has changed. It doesn't matter if I change the volume with keyboard shortcut ctrl+up/down or by clicking the gui. After changing to an ogg file. everything works again (most of the times) but re-starting the mp3, the volume can't be adjustet that smooth, again. I'm using debian sid with qt-interface and alsa. No pulseaudio installed.

30+ seconds seem a lot. 1sec would be expected, but 30? What is your CPU?

It's a core duo with 1.8Ghz but cpu usage isn't climbing while this happens. And even 1sec would be too much for my sense.. This seems too much for such a simple task and I didn't recognize it with vlc 1.1x and I don't recognize it with vlc2 (except for this annoying bug ). The sound is applied mostly instantly. Sadly, I can't reproduce this behaviour everytime. Most of the time yes, but somtimes the volume change will adjust in no time on a mp3 file as well as on ogg. Same file different behaviour. strange.

1sec would be expected

I came here to complain that my volume adjustments take about a second to kick in. VLC 1.x never did this; it was instant. I find even a 1 second lag unacceptable. I hope they can make it as responsive as it was previously.

This depends on your sound card buffer size. If you cannot cope with the latency, use PulseAudio.

I have the same problem on Mac. I can't use VLC2.0 at all.
When I change sound volume in movies there's a delay about 2-5 secs between my change and the actual change of sound.
No such problem on VLC1.0 or any other software.

Is there a solution to this (without installation of some 3rd party software)?

For MacOS, there is a patch floating on the developer's mailing list. It will probably be integrated in VLC 2.0.1.

Sadly, with 2.0.1 on Debian nothing changed. I have streams to test:
While ogg like http://dradio.ic.llnwd.net/stream/dradio_dlf_m_a.ogg works as expected. No delay, volume change reacts instantly.
But as I switch to a mp3 stream like http://87.106.138.241:7000 the dalay lies between 1second and 35+ seconds (I once stopped time and after 50 seconds or so, I thought I forgot to change the volume, because nothing happened. So I canceled the messurement - and after another bunch of seconds the volume changed.) The average time of reaction to volume change commands is around 15 seconds.

Correctly fixing the problem for ALSA would be intricate, would not work on some devices (where rewind is not available), and might cause glitches on some other devices (where rewind is not safe). It would be nice, but nobody stepped up to write all the code. Also, PulseAudio works just fine on Linux.

In any case, I don't see how the latency could be more than 2 seconds, unless your ALSA driver is badly misbehaving.

In any case, I don't see how the latency could be more than 2 seconds, unless your ALSA driver is badly misbehaving.

So how can I find the culprit? At the moment for me it is a regression in vlc 2.x over 1.x, where everything is working like I expect it to be. Where has Alsa to cope with the differences of ogg over mp3 and why does Alsa behave different with both formats? Doesn't Alsa just get a uncompressed "normalized" stream of data to process and the source, like vlc, does the conversion from some fancy (compressed) formats like mp3 or ogg to the "native" Alsa format? If my Alsa driver is misbehaving, why does the latest vlc 1.x work?

Hmm nevermind. The volume latency should be no more than 2 seconds with ALSA, depending on the audio hardware, and nearly immediate with PulseAudio.

The playback latency can be anything. It might just be that the server has a high latency, or that VLC keeps increasing the cache duration to compensate network connectivity problems.

Hmm nevermind. The volume latency should be no more than 2 seconds with ALSA, depending on the audio hardware, and nearly immediate with PulseAudio.

Ok, that would be fine. If it would work. If I have time I should test pulse audio.

The playback latency can be anything.

I did not recognize playback latency. playback is just working fine (with the exception of ogg-streams where vlc sometimes drops packages and stutters, although I increased the buffer.

It might just be that the server has a high latency, or that VLC keeps increasing the cache duration to compensate network connectivity problems.

Cancel this. The volume latency calamity (hey, thats vlc just kidding) is happening on files from the local hard drive as well. It doesn't matter if the ogg/mp3 comes from file or stream, I just saved some minutes of stream to file and the delay problems are the same. On the other hand I tested a non-streamed mp3 and the volume change latency was negligible. Maybe vlc2.x has some regression in the stream playing part? But I didn't test "real" vs. streamed mp3 that extensive.

I just discovered this with the latest version 2.0.1 Twoflower. I have Windows 7 64-bit.

What is funny is that I have never ever encountered this bug before. When adjusting the volume, on all previous versions and on any system I've tried, including this, it has been instant. I have a brand new Asus G74SX as well.
To me it is a delay on about 5 seconds, when I play from a DVD. When playing a file stored locally I get around 1 second (which I also haven't noticed before).

I love VLC but this is just weird.

Edit: Noticed this is for Linux but what the heck.

I've noticed this problem too. It's not my CPU or anything on my end because 3 months ago things were perfect on several different computers and OSes I have. It used to be changing the volume was instantaneous, now there's a lame delay of up to 5 seconds. What's the deal?

This is a side effect of the longer audio buffers available on some audio cards when using ALSA. In previous version, a limitation of VLC was partly hiding the "bug".

On Linux, install PulseAudio and the VLC PulseAudio plugin to fix the problem.