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

[Alexander E. Patrakov]

06.08.2014 12:15, Arun Raghavan wrote:
> 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.

Yes.

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

Yes. And also in your scenario the JS control is visible in pavucontrol.

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

It does make sense. Instead of (or in addition to) the global limit, we 
might introduce a per-group limit or something like that, so that it is 
hit first. But I was talking more about the UI issue, because the limit 
that is _actually_ hit first is the number of UI elements (sliders in 
pavucontrol) that the user is willing to tolerate. I.e. I want to 
enforce the "one slider per tab" rule strictly, even if this means 
excluding some use cases.

-- 
Alexander E. Patrakov