[pulseaudio-discuss] flat volumes for privileged apps

[Arun Raghavan]

On Mon, 2015-10-19 at 16:38 +0200, Wim Taymans wrote:
> Hi all,
> 
> Now that we are talking about flat volumes again (but I don't want to
> hijack the other thread), I would like to present another alternative
> to fix
> the problems with flat-volumes.
> 
> The idea is that all apps, by default, operate in non-flat volume
> mode.
> This means all volume control done from the app is relative to the
> master
> volume.
> 
> Privileged apps can see flat-volumes and thus (indirectly) change the
> master volume. One such privileged app is the volume control applet
> but
> it could be possible to manually enable trusted apps (maybe with a
> switch
> in the volume control next to the app stream).
> 
> I made a little hack to let you try this, gnome-control-center is a
> hardcoded
> privileged app but you can see how we can store that in the database
> later
> or how we can hook this into the security framework.
> 
> http://cgit.freedesktop.org/~wtay/pulseaudio/commit/?h=flat-volume-pr
> ivilege-hack&id=1b203fe6bcc8bba1db1911fd4dbf225f36a6dbb9
> 
> I like this idea because:
> 
> 1) it does not need any new api or changes to apps
> 2) sets a default that will not cause 100% master volume with
> misbehaving
>     apps
> 3) has the master/app volume separation that people understand and
> that is
>     also exposed in apps (volume in totem, master in gnome-shell
> header).
> 4) still exposes the flat-volume model if needed, which is IMHO the
> only way
>     to sanely increase the volume of just 1 single app (when it needs
> adjusting
>     the master volume).
> 5) minimal code changes.
> 
> What do you think?

I think this option is more or less the same as disabling flat volumes.
The user is back to having at least two actions to control volume
(either app slider and panel slider, or open panel and adjust app
slider).

The point of flat volumes was that if you're using the application
volume slider, you don't need to hunt for two volume sliders to adjust
to get the full range of volume that your hardware allows. To my mind,
your proposal makes sense as an alternative to what I suggested only if
we move to a model where we suggests applications do _not_ have volume
sliders at all, and then design the desktop UX differently to provide a
single-action way to adjust volumes.

As an example, the shell could track what the current playing stream is
based on the foreground application and volume controls (hardware and
panel mixer) could track that volume and apply changes as flat volumes.
So the user is always only dealing with one control, by default. (I
just thought of this, so probably needs to be fleshed out to make
sense, or maybe it doesn't at all.)

-- Arun