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
