[RFC] Per-client flat-volumes control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

>
>> Note that Tanu has not flagged my proposal as unfeasible. On the contrary,
>> he said that he could mentor this. So, I would like to see some discussion
>> between you. I do agree that it is not feasible for PulseAudio 6.0.
>>
>> If you still think that it is unfeasible at all, then there is exactly
>> nothing to do on the PulseAudio side. In this case, or if depending on
>> PulseAudio 7.0 is unacceptable, we should propagate the following idea to
>> the browser vendors: "play one stream per tab, mix in-tab sources yourself
>> and apply javascript-settable volumes before sending the result to
>> PulseAudio".
>
> I still think the patch I've posted makes for an acceptable middle
> ground between keeping the usability aspect on the desktop app side
> while mitigating automated volume control on the web side.

Well, no comments here.

-- 
Alexander E. Patrakov


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux