[pulseaudio-discuss] Properties to suppress save/restore of stream volumes

[Tanu Kaskinen]

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