[pulseaudio-discuss] Flat volumes and programmatic volume access (again)

[Arun Raghavan]

Hi folks,
Thought I'd restart this thread since it's been a while. Let me
summarise the discussion so far.

The decision to use flat-volumes has certainly been controversial.
However, I'm convinced it provides a better user experience than the
standard model of having separate per-app and device volumes (even
though this is more familiar).

The problem we face is that some applications set the volume to 100%
arbitrarily, and we'd like to avoid having that affect the system
volume. Most of the cases where this complaint comes from seems related
to applications that allow programmatic access to volume controls
(browsers, gnash, etc.).

We discussed a number of solutions in the past, but the one I'd like to
take forward is what I'd proposed originally -- a per-stream flag to
allow clients to opt out of participating in flat-volume logic. In this
way, programs that know they can't make guarantees of being well
-behaved. We also need a mechanism to force this on clients that we
know aren't well-behaved that we can't change (proprietary and legacy
applications).

The idea is that only controlling the stream within the application's
volume slider would have this non-flat behaviour. Mixer applications
such as pavucontrol would not distinguish this stream from other
streams, and changing the volume from there would behave just as any
other stream. This should minimise confusion from users' perspective,
while disabling the mechanism for rogue applications unexpectedly bump
the volume.

That's how I'd like to see the behaviour work. Now let's talk about
implementation. The previous RFC patch I'd sent communicates the stream
flag for disabling flat volumes to the server, which always disables
flat volumes for that stream. This doesn't work with the behaviour I
described above. So what I think we should do is:

* Streams set a PA_STREAM_DISABLE_FLAT_VOLUME (or
PA_STREAM_PROG_VOLUME_CONTROL or whatever) on the streams for which
they want the new behaviour.

* We add a new stream volume API -- pa_stream_get_volume(),
pa_stream_set_volume(), pa_stream_set_volume_callback(). I think this
is good to have in general, to have a simpler client API. In the
context of this proposal, this allows us to know when an application is
concerned about the stream volume in the stream context vs. a global
context. (this follow's from Tanu's proposal to deal with applications
that play streams as well as implement their own system mixer -- such
as a browser-based system UI might).

* It is not clear to me at the moment whether the new volume API should
be synchronous. pa_stream_volume_get() should be. I think, but I'm
undecided on pa_stream_set_volume().

* I'm inclined to keep the implementation of the relative volume
calculation server-side, in order to keep the client library simple. To
do this, pa_stream_volume_get/set() could reuse the same protocol as
the pa_context_* API but set a flag to let the server know the client
wants relative volumes.

* I'd also like to add a policy module to allow blacklisting specific
applications, and forcing this behaviour on them. This will need a
protocol update to set a stream flag after the stream is connected.

* For legacy apps that are not covered by the blacklist we could add an
environment variable that makes all stream and sink-input volume
-related bits to use the new behaviour.

I've tried to distill out the relevant parts of the previous discussion
to take this forwards. Feel free to bring up anything I might've
missed.

Cheers,
Arun