Volume adjustment lags behind volume bar movement

If you drag the volume bar, the actual change in volume lags behind from 0.5 - 1 second. This can be a problem, because if you drag the bar to max, it sounds like there was no volume change, and then, suddenly, you get full volume.

added Component::Interface: macOS Severity::minor Type::bug + 1 deleted label

changed milestone to %2.0.0 bugs

I can confirm this on OSX Lion with latest trunk build... been like this for all 1.2 builds I tried.

Same on Windows7 with vlc-1.2.0-pre2-20111125-0008-win32 trunk build. vlc-1.2.0-git-20110801-0002-win32 have this bug too, vlc-1.2.0-git-20110613-0003-win32 works fine.

Original author: https://www.google.com/accounts/o8/id?id=aitoawlvuzfhg04vntqcd9hzmfmkwits4isupvi

As mentioned by the previous poster, this is a generic, cross-platform issue in VLC 1.2 due to the event-based volume manager instead of using a timer.

unassigned @fkuehne

added Component::Core + 1 deleted label and removed Component::Interface: macOS label

What the hell is a timer-using volume manager supposed to be? Does this make any sense???

The problem is really simple here.

The buffers are long and the volume is applied in software before buffering: this introduces a long volume latency. VLC has worked like this for years - probably for as long as it has had an audio volume. The correct solution involve implementing set_volume() in the audio output plug-in. Currently, this is done for PulseAudio and WaveOut only.

To work around defective audio output plug-ins, you can keep the caching value low. At the core level, I do not see any reasonable way to fix this. Feel free to file bugs against specific audio outputs if they lack implementation for set_volume().

added Component::Core: Audio output Status::will not fix labels and removed Component::Core label

closed

So after a bit of a dig in the log, there is one change. The maximum caching for audio buffers is larger than before. Thus the maximum filter setting latency is longer.

Still the work around remain the same: reduce caching. And the solution is also the same: implement volume control in the affected output plug-ins.

I am not going to optimize the output for filtering latency, nor for unmaintained audio output plug-ins. Underrun/stutter safety and power consumption are more interesting goals to me.

mentioned in issue #5605 (closed)