GNOME Bugzilla – Bug 724234
volume: Latency maybe too high for quick fade out
Last modified: 2014-05-26 14:37:59 UTC
I would like to implement a instant fade out / fade in when the user clicks pause or play in my music playing application. This is a pretty standard feature in most media players. By "instant" i mean that i want the fade out / in to react immediatly and be complete within 200-400 ms. I've tried to implement this in gstreamer with the following strategies: * Using a volume element and a gst-controller fader to control the volume property. I read the current position of the pipeline and set the next control point X ms in the future with the new volume. * Using a volume element and manually changing the volume-property from separate thread every 20ms or so. Both these method works in general, but the problem is that the audio playback reacts too late to the action. In both cases it seems like the volume actually only starts changing after about 200ms after i start the fadein/out. The methods works fine for e.g. longer crossfading (> 1ms) but the delay is unaccaptable for an instant soft pase / play. I'm guessing the problem is that there is data buffered in the volume element or maybe in the alsasink itself. If i do a flush I get a stutter in the playback which is unacceptable. I've tried various pipelines, but my typical one looks like this: uridecodebin ! audioconvert ! volume ! alsasink. One suggestion to make this possible is to add a "volume" property directly on the alsasink. Would this be possible? Another suggestion is to play with the system volume directly, but this is not possible in my application. Any ideas, suggestions to make this possible? Thanks! \\ Theo
(In reply to comment #0) > Both these method works in general, but the problem is that the audio playback > reacts too late to the action. In both cases it seems like the volume actually > only starts changing after about 200ms after i start the fadein/out. This delay will vary depending on the latency you have configured on the sink element, combine with the latency on the volume element itself. The size of audio buffers will also have an impact. Note that bugzilla is no support forum, I'm marking this as needinfo for now since I think it should be possible to reduce this, though if you get me wrong we'd have to study this a bit. Please provide correct measurements, maybe base on trace points when offering analyses.
Yeah I wasn't sure where to post this, but thought that it could be classified as an "enhancement". I was thinking it probably isn't possible to implement instant soft pause/play considering the way gstreamer works. I am not streaming a live source, just m4a audio files. I have tried with buffering on/off on the uridecodebin, doesn't seem to make a difference. How do I configure or lower the latency for the sink / volume elements? Would you like measurements on the exactly delay? Or what trace points? Thanks,
Theo, see the latency-time and buffer-time properties on the sink. Those can be used to adjust the latency and buffering times inside the audio sinks. Additionally there is also buffering happening everywhere where a queue element exists in the pipeline, potentially adding some latency. If you use pulsesink for output, you could change the volume on it instead of having a volume element. That's going to be almost instantanous (and playbin will use that for its volume property).
Sebastian, I did try to mix with the buffer-time and latency-time properties, but as I remember i did not make much difference. Changing the volume on the pulsesink did become more instant so that is one approach. Unfortunately I had other problems with pulseaudio on my device. I'm not actively using gstreamer for my application any more so I'll close this ticket for now. But thanks for all the support!