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

[Arun Raghavan]

On 6 August 2014 09:41, Alexander E. Patrakov <patrakov at gmail.com> wrote:
> 06.08.2014 09:49, Arun Raghavan wrote:
>>
>> 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.
>
>
> Let me address this now :)
>
> With my proposal, if a web page draws a volume control using some HTML and
> javascript, then it should work, and should control the substream volume
> (which is invisible in pavucontrol). This should have no effect on the tab
> volume as displayed by pavucontrol.
>
> If a web page doesn't draw a volume control, then indeed, the only way to
> control its volume is via the desktop volume control application, or via the
> applet that sets the device volume. However, this is also the situation
> without my proposal, so there is no regression here. And there is an
> improvement: the user sees one slider per tab instead of potentially many.

Not entirely true - with the patch I've posted, for the browser case,
the user needs to worry about the main volume and the custom volume
control that the stream might provide. And usually there are quick
ways to modify main volume (e.g. scroll on the applet icon)

>>> 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.
>
>
> You missed the key point in my screenshot: there is only one tab open, and I
> got three sliders, because the game created three audio elements so far on
> that tab. One slider per tab (even if there are multiple audio elements on
> that tab) is indeed what I want.

That is a good point. The solution is not immediately apparent to me -
one possibly overarching option is to have per-tab volume control
using the stream grouping mechanism I described, but there are likely
to be cases where you _want_ individual control.

What would be ideal is for the application itself to express logical
stream grouping, and for that to be exposed by the browser, and used
by PA to group such related streams for a single volume control.
Perhaps AudioContext [1] is a good fit for this purpose.

-- Arun

[1]: https://developer.mozilla.org/en-US/docs/Web/API/AudioContext