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

[Tanu Kaskinen]

On Mon, 2015-10-19 at 15:19 +0530, Arun Raghavan wrote:
> 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

I think you meant "a problem" :) Badly behaving applications are not
the only issue with flat volumes.

> 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().

pa_stream_set_volume() should be asynchronous like everything else that
requires a round-trip. pa_stream_get_volume() can be synchronous,
because we can cache the stream volume in the client, but we need to
think about what should happen when the client doesn't yet know its
volume. If the server sends the initial volume in the stream creation
reply, this problem doesn't exist, but what should happen with old
servers that don't support that? Could the new API be entirely
unsupported with older servers? That would mean no volume support in
clients that don't fall back to the introspection API... Then again,
maybe it's reasonable to recommend all applications to fall back to the
introspection API for some time, if they don't have guarantees about
the server version.

> * I'm inclined to keep the implementation of the relative volume
> calculation server-side,

If we want a policy module to be able to enforce the behaviour at the
server side, I don't see any other way.

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

How is this compatible with the mixer-app-in-browser use case? How can
the mixer app get the absolute volume, if the browser has set the
relative volume flag for a video app? I think the introspection API
should stay unaffected by the relative volume flag.

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

I'm not against adding the protocol change just for completeness, but I
also think that the protocol update isn't really necessary. I suppose
you mean that clients should get notified if the volume flag changes,
but do clients really need to know? What would they do with the
knowledge?

An implementation note: if the flag is altered during the stream
creation, the final flag value should be sent as part of the stream
creation reply, not as a separate notification message.

-- 
Tanu