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 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? -- Tanu
