On Thu, 2011-02-03 at 08:34 +0200, Tanu Kaskinen wrote: > On Wed, 2011-02-02 at 13:29 +0530, Arun Raghavan wrote: > > Currently Rhythmbox does fading using the GStreamer 'volume' element, so > > this problem doesn't exist with Rhythmbox as it stands now. Some > > background ... > > > > To play audio, Rhythmbox/Totem/Banshee and others use gconfaudiosink > > using the "music" profile. In most systems, this is just directly mapped > > to pulsesink. The pulsesink default buffer-time value is pretty low and > > thus not power-efficient (~15 wakeups/s just from the alsa-sink thread). > > While trying to make the default values for this larger, I ran across a > > problem with the RB xfade backend. Having a long buffer means that you > > introduce a buffer-time-sized latency. Obviously, a 1+ second delay > > between hitting next and the actual fading is not acceptable. > > > > Since GStreamer doesn't support rewinding the stream in any simple > > fashion. there doesn't seem to be a direct approach to fixing this. > > Would implementing rewind support in gstreamer count as a direct > approach? There's clearly a need for it. Since GStreamer is a generic framework, we'd need to be able to rewind any given media, and for video, this is probably not going to be a feasible option. > > Instead, I've been writing a new xfade backend that creates a new > > playbin2 pipeline (and thus new pulsesink) for each stream, and then > > directly controlling the volume on the pulsesink element for fades. > > > > Hope this clarifies the situation. > > Yes, thank you for the clear explanation. > > > > Even with this patch, how can fade-in work? If Rhythmbox disables volume > > > restoring when creating a new stream and fading it in, how does it know > > > what should be the target volume? > > > > Basically, we allow the volume to be restored for the first stream, and > > then maintain the current volume till the end. Thus, when we know we're > > fading a stream in from an existing stream, we don't need to restore the > > volume. > > I now realize that your patch actually breaks things. If the xfade > pipeline disables volume restoring, then volume control through > stream-restore doesn't work anymore for that particular stream. If the > volume of the entry that is being applied to RB is updated by some > external program, and the external program chooses to apply updates > immediately (which is the usual case), then RB volume is not updated. > > I think this particular problem can be solved simply by removing the > should_restore_volume() check from apply_entry(). The check in > sink_input_fixate_hook_callback() should cover the documented > functionality (prevent restoring at stream creation time). This makes sense. > Uh, actually, for sink_input_fixate_hook_callback(), isn't it already > enough that module-stream-restore checks whether the volume is set for > the new stream? You initialize the volume to zero when starting fade-in, > right? Is the restore_volume property completely redundant? Also correct. The question is do we want to have a symmetric interface (set properties for both), or prevent having multiple ways of doing the same thing (set volume vs. set property). I don't see one as being clearly better than the other, so I'll go with the majority (if we decide to include these properties). Ditto for the property name. Replying to the rest in a separate mail. -- Arun
