[pulseaudio-discuss] Per-app flat volume adjustment is highly unintuitive, if mathematically consistent.

[Lennart Poettering]

On Thu, 28.05.09 00:11, CJ van den Berg (cj at vdbonline.com) wrote:

> On Wed, May 27, 2009 at 12:47:28AM +0200, Lennart Poettering wrote:
> > Volume control UIs show the sink's virtual volume in the sink
> > slider. You can change the reference volume by changing the sink slider
> > position. In which case the volume of all sink inputs is adjusted in a
> > way that the virtual volume will match the reference volume. You can
> > change the virtual volume also by changing the stream slider
> > positions, which then doesn't have any effect on the reference volume.
> 
> And this is the core of the entire problem IMHO. The sink volume slider
> *displays* one value (the virtual volume level) and *adjusts* another
> (the reference volume level).  This really, really counter-intuitive and
> a major cause for confusion.  A UI element should never ever carry two
> different meanings.

This is not entirely true. It displays one value, but adjusts *two*
values, including the one that it displays. i.e. after you fiddled
with the slider reference and virtual volume will *both* be set to
what you set with the slider

But yes, you are right, I am tempted to agree that this asymmetry is
problematic.

> > Now, I must admit that this all is a bit hard to grasp. And thus not
> > exactly the definition of easy to use. We had a couple of discussions
> > on this very ML about this. So far noone came up with a way to fix
> > this in a way that would be completely convincing. 
> 
> I still think that my suggestion to drop the virtual volume altogether
> in the UI and have the sink volume slider display the reference volume
> is the right solution.

I am not convinced. Think about this scenario: you have one stream
playing. Reference sink volume, virtual sink volume and stream volume
are at -inf dB. Now you move stream volume to 0 dB. This would not
change the reference volume level, but would set the virtual volume to
0 dB. According to your suggestion the UI would stick to the ref
volume, and hence you get *full* output with the UI showing volume at
-inf dB. I am pretty sure that people would be confused about that
even more than they are with the current logic.

So yepp. We now found that 

a) presenting only virtual volume in the UI sucks

b) presenting only ref volme in the UI sucks, too.

So, what about integrating both values in some way? 

Maybe present max(virtual, ref), as has been suggested by Marc-Andre?
Given that most of the time virtual volume > ref volume, this would be
very similar to a).

Similar for min(virtual, ref), which would be like b).

Show avg(virtual, ref)? Welcome to land of complete confusion!

Present both volumes? Forget it!

Other options might be to handle the cases I) no streams playing II)
one stream playing and III) >= 2 streams playing differently. In fact
that is a bit what happens already, since we actually expose in the UI
the ref vol in case I) and the virtual vol in case II). Beyond that we
could for example make the reference volume  be controllable by the
stream volume, but only in case II) or so. Dunno

This is one messy affair...

> At very least I think it will reduce the confusion level dramatically
> and you won’t have to explain the flat volume logic over and over
> again.

Au contraire!

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4