GNOME Bugzilla – Bug 382423
Need to support smooth volume transitions
Last modified: 2006-12-07 11:05:40 UTC
In the source file gst-plugins-base/gst/volume/gstvolume.c, I see this comment in the function volume_transform_ip(): /* FIXME: subdivide GST_BUFFER_SIZE into small chunks for smooth fades */ On Solaris, we set the buffer size rather large (to 512K) in the SunAudioSink plugin. This causes the delay when changing volume to be somewhat large. On Linux, the delay is maybe 1 second, but on Solaris it is more like 3-5 seconds. Very annoying to change volume in an application like totem or rhythmbox and have to wait 3-5 seconds to hear the change. Any possibility that smooth volume transitions could be supported? If GStreamer engineers could give some advice about how to make this change, I'd be happy to do the work, test it, and get it working. Marking as Critical since with this bug performance for changing volume is very bad on Solaris. Thanks,
Refer to bug #360673 for more information about how we tracked down this problem. In the SunAudioSink plugin, we set the segsize/segtotal values in the prepare function a bit large (to 512K). We were noticing that this large buffer size seemed to cause performance issues with using GStreamer enabled programs: 1) Pressing stop/next/previous buttons in programs caused a 3-4 second delay. After research we discovered that implementing the reset() function in the SunAudio sink/source plugin fixes this problem. Patch to fix this problem is in bug #360673. 2) Changing volume in programs like totem/rhythmbox has a 3-4 second delay. The delay exists also in Linux, but is less severe since we have the large buffer specified above. We think that just fixing volume change so it is smooth and leaving the buffer size a bit large on Solaris is the best approach to fix the performance problems we notice on Solaris. This is better, we think, than fixing the GStreamer engine so that the buffer size can be smaller on Solaris. Refer to bug #360673 for more information about this.
The code portion you mention is totally unrelated to this problem. The comment talks about querying the GstController interpolated value for the volume property multiple times during the loop that applies the volume change. The current implementation applies the same volume change to the whole buffer, which makes no sense for fades. Neither totem nor rhythmbox make use of this.
If your sink needs a large delay, then you need a large delay. There is no way to work around it. What you describe is a problem supposed to be solved in applications: When you modify the set volume, the data that was processed by the volume element beforehand (which is buffered in the sink and elsewhere) becomes "invalid", as you want the change to apply quickly. You could flush out everything from the elements coming after the volume and reprocess the part that was already buffered. GStreamer should provide everything you need to do this, though I doubt it can be done without draining the sink for a short time, causing stuttering. If this shows anything, then it is that such software volume adjustments are just hacks. People expect them to provide instant feedback, which they cannot. Even with the 1 second delay on Linux, using them feels awkward.
Thanks for the comments. Does this imply that some solution like the patch mentioned in bug #360673 in Comment #19 is the right direction to solve the problem on Solaris which causes such a large buffer to be needed. The fact that we need to use a large buffer on Solaris causes the lag when changing volume to be so much worse than on Linux where the buffer is smaller.
yeah, the comment in the volume code is irrelevant and wrong.