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

[Tanu Kaskinen]

On Mon, 2014-08-11 at 19:32 +0530, Arun Raghavan wrote:
> 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).

I mentioned the case of a mixer application like pavucontrol that wants
to show non-flat volumes to the user (maybe with an option to switch
between the two modes). I don't have other use cases in mind.

I don't really agree on the API niceness argument, because in my
proposal there are just two uint32_t fields added (indexes of the
always-relative volume control objects), one to pa_sink_input_info and
one to pa_source_output_info. I don't see much difference to adding a
flag.

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

So the idea is that the browser sees relative volume, but pavucontrol
sees flat volume. This would otherwise work, but since the browser and
pavucontrol use the same API, there's no way for the server to know
which behaviour is desired for a given set or get volume operation,
except by making the flag client-specific, and that seems ugly to me.
What if you want to implement pavucontrol in the browser and the
in-browser-pavucontrol and the stream share the same client connection?
In that case the server has absolutely no way to distinguish which
behaviour is wanted for a given get/set volume operation.

One solution would be to add pa_stream_set_volume() and
pa_stream_get_volume() functions instead of the flag, which would be
available only to the stream owner. Those functions could then have a
boolean argument for deciding between relative/absolute. But then this
is certainly not any simpler than the two added integers that I proposed
for the introspect API...

-- 
Tanu