Changing volume has a slight lag on Mac using the default audio output
As directed by courmisch in #5596 (closed), separate tickets should be logged for each output plugin to implement set_volume().
So here is the one for Mac OS X, IIRC it uses CoreAudio.
Although the explanation given in #5596 (closed) seems a bit strange since it works fine in the 1.1 branch. Maybe the default cache latency change...
Anyway, it's rather annoying so I guess it should be fixed at some point... although there are much worse bugs to tackle... so priority is set to lowest.
Activity
changed milestone to %2.1.x maintenance bugs
Related: #5654 (closed)
I have just attached coreaudio_hardset_volume.patch. It is not ready for commit, but is one possible solution that needs to be discussed.
The patch solves the annoying delay problem by setting volume via hardware rather than software [i.e. a volume change in VLC changes the OS X volume level as well]. This works splendidly and I'm running the build as my primary one so I don't have that annoying delay issue. However, this approach has some issues.
You'll notice in the patch that I multiply the volume level by 0.5. This is because the AudioUnit volume level range is between 0 and 1 [0 to 100%], but VLC allows volumes up to 200%. Anything above 100% would have no affect, so I do this quick hack to make the volume slider work as expected. That is, 100% is as loud as it gets. I think the majority of common users also expect this kind of behavior from perusing the forums. Having said that though, there are benefits to allowing a volume greater than 100%, particularly on quite audio etc. The problem though is how to achieve this.
One possible solution is to take a hybrid approach: in the 0 to 100% range we employ a hard volume set, and anything above that we fallback on a soft volume set. Unfortunately, this only gets us half way out of the sand. Anything above 100% and we'll start experiencing audio delays again. This could be even more annoying to users when volume in the first range set is realized immediately, but then anything in the second set incurs a delay.
A second approach is to accept the tradeoff and set the max volume to 100 [either globally or for the OS X build], and then provide some other mechanism through which we can offer additional volume boosts above nominal level.
An alternative approach would be to solve the delay problem for the soft volume set, which I believe requires sizing down the buffer if I understand the other tickets. I don't know anything about that part of the system [and this is my first foray in to the VLC codebase to begin with, I won't go there, but perhaps someone more knowledgeable].
The max volume was reduced to 200 from 400 sometime in the past to bring the max level within some ~20dB range recommendation. The equalizer already provides the capability to move up or down 20dB, so it seems on the surface that changing the volume max to 100 would not hamper the ability to boost the volume level beyond nominal values through the equalizer. If that's not satisfactory, we could provide a similar mechanism through effects to allow boosting of low sound levels separate from main volume control. At least it makes sense to me, but what do you all think?
Beyond the elimination of the audio delay [in auhal], here's an example of how linking VLC audio to the OS volume level would be beneficial. I have volume control for my sound system, OS volume control, and then VLC volume control. Every time I want to use VLC, I have to spend a few seconds testing audio levels. I have to make sure the OS volume is in a sweet spot and in good relation to the sound system volume control, then I have to make sure the VLC volume is centered and in a sweet spot in relation to OS volume control. All of this, so that when I change the volume with a remote, the change in loudness of each step is just right, and that I don't hit the VLC 200% max. Granted this may be somewhat of an edge case [since my sound system does not have a remote], so the remote controls the OS volume [or VLC as it currently stands]. One counterpoint though is if someone wants to have a video playing without sound [muted] or turned down, while at the same time having audio playing from another source... I've never wanted to do that, but perhaps there are some that do?
Thoughts?
My thought is that you should send this patch with this explanation to vlc-devel@videolan.org for more feedback.
VLC volume should not control the system Volume. I don't need changing the volume in VLC to mess with the levels of everything else on my system especially since the volume levels in videos are so erratic.
As mentioned in the other ticket, it makes the most sense to adjust the audio on output so the change is immediate rather than delayed by any buffering.
Great news everyone! I found the elusive call that was needed.
This patch is a win-win. It retains current behavior [audio control separate from operating system], and it completely removes the lag when changing volume for analog output through CoreAudio.
Take a look and give it a go.
Edit: one possible note is that the Apple documentation says this parameter is a linear gain between 0 and 1, but it appears to accept values greater than 1. For example, the patch uses the cubic mapping from the soft volume set in output.c and it seems to work fine. This number ranges from 0 to 8. Perhaps the Apple documentation is incorrect, or is referring to an older SDK? I tested the 10.7 SDK.
assigned to @jmstacey
changed milestone to %2.0.1
I backported this fix to the stable branch now, since it also works nicely on 10.5.
@kdean: i can reproduce this and this should be solved for 2.0.1.
Good catch! However, this particular problem was not introduced with this patch. From what I can tell it has existed in 2.0.0 [and master] to date. I've been digging around code and I'm not exactly sure how any audio module is initializing the starting volume [if they are indeed working properly] whether by soft set or hard set.
One possible solution is to set the initial volume when aout_VolumeHardInit() is called. Will this have ramifications on other modules? Conceptually nothing is really changing. Their respective volume callback is called immediately upon initialization, and aout_VolumeHardInit() no longer creates the volume and mute variables since they should already be set [and aout_VolumeSoftInit() does not create them either]. Patch attached.
Another alternative solution is to deal with this inside each audio module itself, but it seems like there should have been an external call to initialize the starting volume. After all, why have a volume callback if it's not going to be called? Personally, I would have expected it to be called when the audio device was initialized and registered itself with volume control...
In any case, I have patches for both solutions, so the choice is yours :-)
Audio: have aout_VolumeHardInit() call the setter to initialize starting volume, and stop creating volume and mute variables.
Added attachment:
Audio: Core Audio: Initialize starting volume for analog devices.
Added attachment:
added Status::fixed label
mentioned in issue #5654 (closed)
mentioned in issue #5745 (closed)
