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
