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
