[pulseaudio-discuss] [RFC] Per-client flat-volumes control

[Alexander E. Patrakov]

06.08.2014 14:45, Tanu Kaskinen 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, I will go to GstConf.

>
> Ok, so we have two proposals for preventing web apps from having access
> to flat volume:
>
> 1) Disable flat volume for individual streams.

Please note that Arun's patch does more than just this. It also 
introduces an environment variable that triggers this logic.

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

It looks like a good proposal, especially useful for simple cases where 
there is only one stream.

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

I have an opinion on this, but let's respect Arun's request to discuss 
this in a separate thread.

>
> 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 think that I can make an additional (possibly unfeasible) strawman 
proposal, more in line with (1), that partially takes this into account. 
Here it is:

4) Make PA_STREAM_NO_FLAT_VOLUME a client-only flag that is accepted in 
pa_stream_connect_playback() and friends, but not encoded in the 
protocol. The fact that the flag has been specified should be remembered 
by libpulse. Every time the client wants to change the volume, the 
library should query the sink volume, convert the desired volume to 
possibly-flat, and encode the resulting possibly-flat volume into the 
protocol. Also, the library should convert the volume for this stream 
from possibly-flat into non-flat representation on introspections, and 
update the client's idea of the volume when it uses the subscription 
interface to be notified about volume changes (be it from the sink or 
from the sink input). All other mixer applications should see the 
resulting possibly-flat volume.

If this is feasible, then I would rank it above (1), but below (2) and 
(3). And of course, if (3) is implemented, then (4) becomes unneeded.

-- 
Alexander E. Patrakov