On Wed, 2014-08-06 at 13:31 +0530, Arun Raghavan wrote: > I guess we're in disagreement there. We can discuss this further, > either in a separate thread, or at GstConf (or both), but I would like > to get some more opinions on getting this patch in soon, since it's a > practical fix that we can use now. Ok, so we have two proposals for preventing web apps from having access to flat volume: 1) Disable flat volume for individual streams. 2) Introduce substreams that the browser would group under a single tab stream. Web apps would only have access to the substream volumes, which would not interact with the flat volume logic. I have one of my own (I already mentioned this in [1]): 3) Add a second volume control to streams, one which represents the stream's own volume only, i.e. never flat volume. Applications that want to avoid flat volume can use that volume control instead of the primary volume control. Even if proposals 1 and 2 are implemented, I'd still like to implement proposal 3 too, because it's simple (I need the second volume control at server side anyway, and adding it to the client API is just a matter of adding one field to pa_sink_input_info and pa_source_output_info) and because it provides some new possibilities for applications: for example, pavucontrol could have an option to not show flat volumes even when flat volumes are enabled. If proposal 3 is implemented, proposal 1 becomes unnecessary, so I'd prefer to not merge Arun's patch. The per-stream disabling of flat volume also makes mixer UIs behave oddly. Alexander mentioned inconsistency in what is the "desirable" position for different streams, but I think a bigger problem is that strange things will happen if a flat volume stream pushes the device volume up. If there's also a non-flat volume stream playing to the same device, there are two ways to deal with that: either the non-flat volume stream's volume appears to go down in the UI (while there's no real change in volume), or alternatively the non-flat volume stream's volume appears to stay the same in the UI, while in reality it grows along with the device volume. Proposal 2 solves additionally the problem of too many streams in mixer UIs, so that's not made redundant by proposal 3. If someone is willing to implement the substream concept, great. [1] http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/19752/focus=20703 -- Tanu
