GNOME Bugzilla – Bug 522256
rhythmbox volume control lags
Last modified: 2011-07-24 23:33:40 UTC
Bug reported at https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/160565 Rhythhmbox's volume control lags a few secs when with mouse wheel This is not a major issue, but it is uncomfortable to tell the volume control to up/down and not getting immediate response. It doesn't happen with any other app.
Bug found within Ubuntu Hardy 8.04, rhythmbox 0.11.4-0ubuntu6, i386
That's because it's a software volume control, so its latency is determined by the downstream elements in the pipeline and the size of the audio device's buffers.
Mmmm, I don't get it. If latency is determined by audio device's buffer, it should decrease if rhythmbox is the only app making use of the device, right? and increasing latency would be detected if there were more than one app using audio device. That's not the case, if i get totem-gstreamer and rhythmbox playing something, totem's volume control acts as expected (no such delay), while rhythmbox's volume control keeps on delaying.
Why do you think the buffer size works like that? If crossfading is disabled, the rhythmbox pipeline is fairly different to the one totem uses. If crossfading is enabled, the pipeline is completely different.
Jonathan: are you saying that this behavior is normal/expected? I agree with Francisco in that the delayed volume response causes a certain level of ambiguousness when using it. If this delay won't be fixed, maybe a different approach to the volume control could be considered. Gutsy 8.04(beta) and Rhythmbox 0.11.5, but I believe I've seen this delay in previous versions up to 1yr ago. The LaunchPad link above indicates it's been around since at least '06
It's a software volume control. There will always be a delay. What alternative approaches to the volume control are there to consider? One option that has come up is to use the pulseaudio stream volume control (rather than a gstreamer volume element) when using pulseaudio sink.
Created attachment 108260 [details] rough draft of RythmBox volume slider within the balloon I guess this idea isn't so much a solution to the lag but more feedback to the user: provide immediate visual feedback of the volume level. Something that would make it obvious to the user that the input was in fact received, and gives the user some idea of what the volume will be when the software catches up. Attached is some (crude) artwork showing an example. Notice how big the display is compared to the tiny volume icon. This makes it clear to the user that the program is responding, and they'll learn quickly to expect a delay in the volume control.
Created attachment 108309 [details] balloon example #2 better example of visual feedback for impending volume changes; this value should update close to real-time to allow the user to know the requested sound level will eventually be achieved.
I have the same volume lag and it is extremely annoying as I have very powerful speakers and rhythmbox blasts at 100% volume when I start it, taking about 10 or more seconds to lower the volume. Also, when I change from radio to music or vice-versa, the volume slider gets reset to 100%! This only happens in rhythmbox, so I don't think it has anything to do with the audio buffer size or whatever. Every other app, using gstreamer or not, does not have the same problem. For example, using totem I do not get this annoying delay, the volume changes instantly. This is also not soundcard related, as both my internal intel HDA and external usb soundcard have the same issue. It also happens when using the jackaudiosink with gstreamer. Please let me know if you need any more info. Regards, Pedro