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

[Mark Greenwood]

On Wednesday 27 May 2009 23:31:29 Lennart Poettering wrote:
> 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
))
I'm not sure I have completely followed and/or understood the complete argument here but, UIs are kind of my area of expertise. Ignore me if I'm rambling or ranting but, it's my experience (15 years worth) that developers tend to view things from a neatness of code point of view, whereas users tend to view things from an intelligibility of the UI point of view. What is satisfying to the developer is often not what the user wants or understands... realising what the user needs often results in horrid and messy code but happy and productive users. What conclusions have I drawn from this? (a) Existing coding models are crap. (b) you can't please end-users with beautiful algorithms, (c) UI design should be independent of the underlying code and really ought not to directly reference any of the features of the driver model. My manager would shoot me at this point.. the people who use my software are not complaining however.

(c) Is really the point I think is relevant to this discussion. If the UI of pavucontrol is making end users confused then either (a) redesign the interface so the bits that confuse them are masked by brilliant and inventive mappings or (b) redesign the backend such that the existing UI makes sense. In my experience, (a) pleases most of the people most of the time. In other words. it's not the logic that is the issue, it's the way that logic is displayed to the user. As I'm fond of saying - find out what your users want to do, then map what your application actually does onto those desires, then design a UI that controls the mapping - leaving the backend free to do as it pleases. Forget the underlying logic - it is usually influenced by hardware designers and is therefore meaningless to normal people ;)

People expect a volume control to work in a particular way. What you have to establish is how they expect it to work. If your backend logic does not follow that (and it probably doesn't, for all sorts of very excellent reaasons) then your UI needs to map between expectation and reality, rather than directly controlling the exposed backend API. This way keeps everybody happy. I write software which controls extremely complex automation environments, and it is useable by people with no understanding of the word 'automation', I therefore believe I know what I'm talking about.. but it is late and I am drunk so forgive me if I talk shite,,, :)

Mark

>