On Thu, 2011-02-03 at 19:19 +0200, Tanu Kaskinen wrote: > On Thu, 2011-02-03 at 10:37 +0000, Colin Guthrie wrote: > > I guess the real problem would be how to interface with xfade in gst > > such that gst applications would be essentially ignorant of "how it's > > done", such that gst-on-alsa works as transparently (to the app) as > > gst-on-pulse. > > I'm skeptical about the feasibility to do this fully transparently. If > the backend doesn't support cross-fading, transparency would probably > mean that alsasink (and pulsesink too if the daemon doesn't have the > support enabled) would have to implement cross-fading inside itself... > Or maybe the answer is a xfadesink, which is a bin that builds the > required pipeline behind the scenes if the final sink doesn't support > cross-fading? Arun probably has a better idea of this side... I'm still trying to work out the best way to integrate this with the GStreamer folk, but as basic background. GStreamer has a Controller API that basically allows you to set a property (volume being a property here) from value 'va' at time 'ta' to value 'vb' at time 'tb' using a specified interpolation method for intermediate points (GStreamer supports a number of these). Wim suggested having a way to take the control values and pass them to PulseAudio and have it handle that, which should be workable. > > I'm not sure how this would work in practice at the PA end, but I would > > guess some kind of protocol/API extension (as is done for m-s-r and > > m-d-m right now) rather than a part of the core protocol (but perhaps > > this would be justified?). > > I would definitely do it in a module + an extension. A track-change > cross-fade would be possible without an extension API, though, and > probably also fade-in: just set properties > "module-xfade.previous-stream" and "module-xfade.duration" (optional). > No protocol extensions needed. previous-stream would be the index of the > stream to fade out (maybe a negative number for fade-in, ie. no previous > stream). The cross-fade processing would automatically start when that > property is detected by module-xfade on a new stream. Fade-out would > have to be signaled through some extension API still. I don't know if > fade-in and fade-out are in the requirements, though, or is cross-fade > the only thing that's needed? I'd thought of this when I started doing the fades on pulsesink but was hoping I could get away with a less intrusive solution. Alas, it was not meant to be. :) Since the application knows better than PA when a stream is meant to be faded (end of stream, start of playback, hitting next/previous, play/pause), I think the actual control of fading should be left there. On the PulseAudio side, we would extend the API with something like pa_context_set_sink_input_volume_with_ramping() which takes a target volume and fade-time (by now you're probably going "A-ha! There's already a pa_sink_input_set_volume_with_ramping()!" ;)). IMO this is cleaner because it effectively separates mechanism from policy and prevents us from having to worry about fade-in, fade-out and crossfade separately. Things to worry about here: 1. Interaction with module-stream-restore: ideally, m-s-r should just store the final volume and ignore all intermediate values, which afaict is how the ramping code works already. 2. Volume changes in the middle of a ramp: there's already some logic there to handle overlapping ramps. 3. Notifying clients: when the fade is done, clients would need to be notified (in RB's case, to cork/destroy the stream on fade-out). There are two ways to do this - emit the changed volume after the fade is done or add a new fade-done notification. I would vote for the latter since it is independent of other volume changes that might happen in the course of a fade. Cheers, Arun
