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

[Arun Raghavan]

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