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

[Arun Raghavan]

Hey Tanu,

On Wed, 2011-02-02 at 09:04 +0200, Tanu Kaskinen wrote:
> 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?

Currently Rhythmbox does fading using the GStreamer 'volume' element, so
this problem doesn't exist with Rhythmbox as it stands now. Some
background ...

To play audio, Rhythmbox/Totem/Banshee and others use gconfaudiosink
using the "music" profile. In most systems, this is just directly mapped
to pulsesink. The pulsesink default buffer-time value is pretty low and
thus not power-efficient (~15 wakeups/s just from the alsa-sink thread).
While trying to make the default values for this larger, I ran across a
problem with the RB xfade backend. Having a long buffer means that you
introduce a buffer-time-sized latency. Obviously, a 1+ second delay
between hitting next and the actual fading is not acceptable.

Since GStreamer doesn't support rewinding the stream in any simple
fashion. there doesn't seem to be a direct approach to fixing this.
Instead, I've been writing a new xfade backend that creates a new
playbin2 pipeline (and thus new pulsesink) for each stream, and then
directly controlling the volume on the pulsesink element for fades.

Hope this clarifies the situation.

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

Basically, we allow the volume to be restored for the first stream, and
then maintain the current volume till the end. Thus, when we know we're
fading a stream in from an existing stream, we don't need to restore the
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.

I've no objection to changing the namespace of the property itself. Do
you also mean that we should change the define, though?
PA_PROP_MODULE_STREAM_RESTORE_RESTORE_VOLUME seems unwieldy to me, and
there's no reason that clients should need to know about
module-stream-restore.

Thanks for the review,
Arun