[pulseaudio-discuss] [RFC] Per-client flat-volumes control

[Tanu Kaskinen]

On Wed, 2014-08-06 at 16:42 +0300, Rémi Denis-Courmont wrote:
> Le 2014-08-06 16:10, Tanu Kaskinen a écrit :
> > The answer to your question: no, the normal stream volume and the
> > relative volume are very tightly tied together (and when flat volumes
> > are not in use, they're exactly the same thing). You can't change one
> > without affecting the other, and both are expected to be
> > user-controlled.
> 
> Then I don't really see how and why the PulseAudio daemon would have to 
> care about that new volume.
> 
> The browser can simply divide/multiply the stream volume by its 
> source/sink volume if the flat volume flag is on. You might or might not 
> want to provide libpulse-level helpers for it, but that's pretty much 
> it, AFAICT.

My original motivation for the new relative volume control was on the
server side. When I implemented audio groups, there was a need to form
master-slave relationships between volume controls: audio group volume
controls could be masters for other audio group volume controls, and
also for stream volume controls. Having a master-slave relationship
means that when the master volume changes, the same change is propagated
to slave volume controls (and also the other way around, so the
relationship is more like peer-to-peer, but a hierarchical structure
makes the traversal easier when propagating the changes). I got
frustrated when it turned out to be rather complex to propagate the
volume between audio groups and streams. I expected the operation to be
simple, but since the audio group volume represents the relative volume,
I had to add special casing to the propagation code in case the slave
was a stream volume control. When doing master->slave propagation, I'd
have to check if the slave was a sink input or source output, check
whether the sink or source had flat volume enabled, and if so, remap the
sink/source volume to the stream channel map, then divide the propagated
volume by the sink/source volume, and finally call
pa_control_set_volume() on the slave volume control. When doing
slave->master propagation, similar dance is needed. With a separate
relative control the propagation is very simple.

I'm not sure that the separate relative volume control approach results
in fewer lines of code, but I like it for several other reasons:

 * The volume control code doesn't have to do any special casing
depending on what the control is being used for.
 * The volume controls that share the volume with each other have the
exact same volume instead of stream volume controls being affected by
the sink/source volume.
 * The stream relative volume is visible in "pactl list
volume-controls", which can be nice for debugging. This could be
achieved also by implementing the flat->relative conversion logic in
pactl, but with the separate relative volume controls this feature comes
for free.
 * If the relative volume controls are exposed to clients, implementing
that is much simpler than some kind of libpulse-only helper thing that
would have to make an extra round-trip for getting the sink/source state
and do the volume calculations.

-- 
Tanu