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

[Arun Raghavan]

On 6 August 2014 10:28, Alexander E. Patrakov <patrakov at gmail.com> wrote:
> 06.08.2014 10:20, Arun Raghavan wrote:
>>
>> On 6 August 2014 09:41, Alexander E. Patrakov <patrakov at gmail.com> wrote:
>>>
>>> 06.08.2014 09:49, Arun Raghavan wrote:
[...]
>> 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)
>
>
> If you say that, then there is obviously some misunderstanding. Let me
> restate what should work is the page does provide an HTML-based volume
> control:
>
>  * main volume (scroll on the applet icon, or go to the Output Devices tab
> in pavucontrol);
>  * tab volume (visible in pavucontrol on the Playback tab);
>  * HTML-based volume control (visible in the web page, does not correspond
> to any slider in pavucontrol).
>
> If PulseAudio is configured to use non-flat volumes, that we have three
> factors that, when multiplied, determine the loudness of the sound that
> should come out. If flat volumes are in effect, then the first two should
> work in the usual flat fashion (with the main volume being the maximum of
> all tab volumes and volumes of non-browser applications, and changing them
> all when being changed by the user), and the HTML-based volume control
> should apply in a non-flat fashion on top of the tab volume.

I think we're talking across each other a bit. I think I'm describing
what we have (in which there isn't a per-tab volume just per-stream),
and you're talking about what you would like to have.

What I was referring to was that in my scenario (we have per-stream
volumes, and global volume), if the browser disables flat-volumes for
all its streams, then you have two controls - the JS/browser control
on the page, and the main volume.

[...]
>>> 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.
>
>
> Then our disagreement is that you think that your option is possibly
> overarching, while I think that it is the only valid one. My more detailed
> viewpoint on this issue is:
>
>  * If the application author thinks that there is a use case for the
> individual control via an external application (the "external application"
> clause is important), he should not group streams.
>  * All sounds on the same tab should be grouped unconditionally, because
> there are web pages that leak (never close) old streams while creating new
> ones.
>  * Javascript-based volume APIs should still be able to change the volume of
> each audio element programmatically and independently, as required by the
> HTML5 spec.
>  * And, of course, javascript-settable volume should apply in a non-flat
> fashion on top of the tab volume.
[...]
>> [1]: https://developer.mozilla.org/en-US/docs/Web/API/AudioContext
>
>
> Well, I am not sure. The doubt comes out from the possibility of an
> incompetent web programmer to create many stupid audio contexts from the
> same tab, thus again returning the slider-pollution problem.

I think that sort of use should be considered bad behaviour (on any
system, creating and not freeing resources will inevitable hit a
limit), so trying to deal with that might not make sense.

-- Arun