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:
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)
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.
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.
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.
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.
Yes, exactly. But note that the application should still be able to set
relative-to-group volumes on the group members.
Perhaps AudioContext [1] is a good fit for this purpose.
-- Arun
[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.
--
Alexander E. Patrakov
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
