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

[Tanu Kaskinen]

On Tue, 2014-02-18 at 21:39 +0530, Arun Raghavan wrote:
> 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.).

This doesn't force the policy at all. I didn't mean that there must be a
device that has the same volume control as the main volume. I meant that
if the main volume controls a device volume, then that association can
be expressed by using the same volume control object for both the device
and the main volume. If the main volume controls a volume class, that
relationship can be expressed in the same way: the volume class has the
same volume control object as the main volume.

If you think this is too clumsy, can you give a better proposal?

> >  * 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.

No, I don't mean that. I mean if there's a volume class for music, then
the volume UI can show all music streams under the volume slider of the
music volume class. That is, the user sees which streams are actually
affected by the volume class volume.

-- 
Tanu