[pulseaudio-discuss] RFC: New volume functionality for PulseAudio

[Arun Raghavan]

On 11 February 2014 19:33, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote:
[...]
> The alternative for separate volume controls is that we keep embedding the
> volume in various other objects, like sinks, sources, ports (which, btw, are
> currently missing volume control altogether when they are inactive), sink
> inputs and source outputs. This is certainly a possible approach, but I very
> much prefer the separate volume control object idea.
>
> Benefits of separate volume control objects:
>  * Solves the problem of figuring out what the main volume controls. For
> example, the Gnome volume applet shows a headphone icon when the main volume
> controls the headphones volume. The volume applet can check if the main
> volume points to the same volume control object as the headset port.

This is a bit clumsy, imo (mixers having to iterate over devices to
find which one they're controlling), and more importantly, forces the
policy to be "main volume == some device volume", which might not be
the case. For example, on a phone, the main volume might end up
corresponding to the volume of some volume class (music if there's
music playing, ringer if there isn't, etc.).

>  * If two streams share the same volume, a pavucontrol-like application can
> group the two streams under one volume slider.

I assume you mean for cases such as virtual sink-inputs and
source-outputs that we use for filters? These aren't meant for the UI
anyway.

>  * Opportunity to separate the overall volume from the channel balance. The
> pa_cvolume volume representation loses all balance information when the user
> slides the overall volume to zero.

As already discussed, this doesn't really need the volume to be an object.

>  * Flexibility to easily add new volume control objects for whatever purpose
> in the future. For example, there could be a volume debug mode where the
> individual alsa volume elements would be exposed as read-only volume
> controls, or separate read-only volume control objects for the "reference",
> "real" and "soft" components of sink volumes. pactl could show and control
> all volumes without understanding what the volumes are associated with.

Since I don't really see the volume objects as being needed for the
reasons you stated above, I'm not keen on adding them for potential
future use.

Cheers,
Arun