06.08.2014 12:15, Arun Raghavan wrote:
On 6 August 2014 10:28, Alexander E. Patrakov <[email protected]> wrote:
06.08.2014 10:20, Arun Raghavan wrote:
On 6 August 2014 09:41, Alexander E. Patrakov <[email protected]> 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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
