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

[Alexander E. Patrakov]

19.10.2015 14:49, 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 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.

This looks like a good proposal overall.

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

OK.

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

This indeed looks simpler than the existing introspection API.

> * 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 have no opinion here.

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

The question here is whether we would later want to force this upon all 
sandboxed applications (xdg-app).

-- 
Alexander E. Patrakov