On 6 August 2014 14:15, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote: > 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. While in theory I like this, I have one pretty large reservation - I would like to only expand the API for clearly defined use-cases. If not, adding another volume control for very specific use cases makes the overall API more complex for the general case (I am approaching this from a usability point-of-view for developers trying to understand and use our API). Do you see concrete client-side use-cases for this other than the flat-volume case I'm trying to solve (for which, I think my solution is nicer from the API perspective, if not as clean as yours, implementation-wise). One option is to have the relative volume not be exposed as API, but be the volume that is controlled if this stream flag is set (i.e. pa_sink_input_set_volume() would modify the relative volume if the stream flag is set). > 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. I'm a bit confused about what you mean here. Will try to sync on IRC about what this implies. Cheers, Arun
