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
