On Tue, 2011-02-01 at 20:25 +0530, Arun Raghavan wrote: > Hey folks, > While playing with Rhythmbox a bit, I found myself needing to suppress > saving/restoring of stream volumes sometimes, namely when a stream needed to be > created + faded in or faded out + destroyed. While it is possible to manage > this in the client with some extra logic (ignore volume notifications when > starting up and cork and reset volume after fade out), I thought it might be > nice to have a simpler way to control this. > > I'm attaching a patch to add new properties (in a new "stream." namespace) that > do this. It does make the client code look nicer, and if nobody has any major > objections, could probably go in. So this patch works around problems with fade-in/fade-out. Does Rhythmbox do the fading by telling Pulseaudio to change the stream volume? I guess so, because that's the only way I can see how fading interferes with module-stream-restore. If the fading would be done at the client side using software attenuation, then there should be no problems, right? Can you enlighten me - why is doing the fading at client side not good enough? 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? About the namespace: the properties are module-stream-restore specific, so I think the namespace should be "module-stream-restore" instead of "stream". I know that pa_sink_input has field save_volume that is managed in the core, so that makes the volume restoration feature sort of part of the core, but I think that's so just because making module-stream-restore fully self-contained wasn't seen worth the required effort. Using the "module-stream-restore" namespace doesn't induce any extra effort, so I think it should be used. -- Tanu
