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

[Arun Raghavan]

On 6 August 2014 09:09, Alexander E. Patrakov <patrakov at gmail.com> wrote:
> 06.08.2014 06:31, Arun Raghavan wrote:
>>
>> On 6 August 2014 01:12, Alexander E. Patrakov <patrakov at gmail.com> wrote:
>>>
>>> I think that the real problem that needs to be solved is not only that
>>> flat
>>> volumes are inapplicable to the web, but also that PulseAudio doesn't
>>> provide any API for intra-application mixing. Please see my earlier
>>> thoughts
>>> on it here (point 7):
>>>
>>>
>>> http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-February/019968.html
>>>
>>> In other words: please add new API that would allow a browser to
>>> implement a
>>> per-tab (flat or non-flat, as configured in daemon.conf) visible volume
>>> control, with several substreams being mixed for each tab by PulseAudio.
>>> The
>>> javascript inside the browser should be able to set, invisibly for the
>>> user,
>>> tab-relative (and thus non-flat) volumes for each substream.
>>
>>
>> I don't think this really feasible - in this case, you need some way
>> to control per-tab volume as well, and that's a UI change that we are
>> in no position to effect across browsers.
>
>
> Yes, what I am proposing is a big change in the volume model. External UIs
> such as pavucontrol should still be able to introspect and control stream
> volumes as usual, but a new class of streams (those that don't send samples
> themselves, but only allow their slave substreams to do so) would be
> introduced. Substream volumes should not be introspectable and should apply
> in a non-flat fashion on top of the stream volume.
>
> Browsers are expected to create this two-level hierarchy of streams: one
> master stream per tab, with a description matching the tab title, and as
> many substreams for that master stream as there are audio elements or other
> sound-producing HTML5 thingies on that tab.

Adding such a mechanism would not be as painful as adding a new type
of stream to just set volumes. We could just as easily add a
per-application volume mechanism and apply that as a volume factor on
all of an application's streams. That's not to say I think this is a
good solution to this problem.

You didn't address my actual concern here - making such a change would
either require the user to use their desktop volume control to change
browser volume, or have browsers have a volume control widget for the
browser volume. The first makes for bad UX, the second is impractical.

> Basically, not what's on the attached screenshot (taken with non-flat
> volumes). Any browser that does this "three sliders with meaningless titles
> in one tab" thing is buggy.

The titles should be more meaningful, in which case I find this to be
acceptable UI - I can then modify per-tab volumes from the mixer, if I
wish.

> Note that Tanu has not flagged my proposal as unfeasible. On the contrary,
> he said that he could mentor this. So, I would like to see some discussion
> between you. I do agree that it is not feasible for PulseAudio 6.0.
>
> If you still think that it is unfeasible at all, then there is exactly
> nothing to do on the PulseAudio side. In this case, or if depending on
> PulseAudio 7.0 is unacceptable, we should propagate the following idea to
> the browser vendors: "play one stream per tab, mix in-tab sources yourself
> and apply javascript-settable volumes before sending the result to
> PulseAudio".

I still think the patch I've posted makes for an acceptable middle
ground between keeping the usability aspect on the desktop app side
while mitigating automated volume control on the web side.

-- Arun