[pulseaudio-discuss] Properties to suppress save/restore of stream volumes
Tanu Kaskinen
tanuk at iki.fi
Tue Feb 1 23:04:18 PST 2011
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
More information about the pulseaudio-discuss
mailing list