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

[Tanu Kaskinen]

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