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