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

[Lennart Poettering]

On Mon, 25.05.09 12:51, Jud Craft (craftjml at gmail.com) wrote:

> I understand how audacious it would be to post and tell you that
> Pulseaudio is doing the volume scaling wrong, but let me demonstrate a
> problem.  I won't post twice -- I know you guys are busy on this list
> -- but I've really wanted to mention this.  I've seen Redhat Bugzilla
> #494112, but it seems to glance over the problem.
> 
> I know that Pulse can remember the volume of an app.  And when Pulse
> also scales the main-system volume (with only one program, App A,
> present), it remember that app's volume, say 75%, and sets the main
> system volume to it.  All is good.  Set App A to 75%, and Pulse sets
> the system volume to 75%.
> 
> But what happens when you run another program (App B), that has a
> per-app volume of 80%?  It appears that Pulse remembers the volume of
> App B too.
> 
> In this case, it appears that Pulse rescales both apps, so that the
> main system volume matches App B (80%), and App A is set so that it
> has a relative volume to App B.  (ie, if App A has only 75% of the
> main system volume, and 80% is the main volume, so App A now has .80 x
> .75 = 60% volume).

Uh? No, that's wrong.

First of all, using percentages for this is misleading. The percentage
scale is artificial and has only an indirect connection to what
happens internally. It is explicitly *not* a factor that is used for
actual volume adjustments.

If you have one stream A at linear volume factor X and one B at linear
volume factor Y with X < Y, then the device will be configured to Y
and internally the data from B will be passed through untouched and
the one from A will be attenuated with the factor (X/Y). That is
completely different from what you wrote above.

> This maintains the correct per-app ratio (App B is louder than App A),
> but it changes the main system volume.  In addition, if a program that
> has no per-app volume yet (with a default of 100%) is launched, then
> Pulse resets system volume to 100% and scales _both_ apps to match
> this one.

That is not correct.

PA will set streams it doesn't know to 100% of the 'reference
volume'. The reference volume is the one you configure on the sink
with the UI. i.e. if you change the sink volume to 75% then a new
previously unknown stream will be configured to 75%. However if you
set the sink volume only indirectly to 75% (i.e. by controlling
setting a stream volume to 75% with it being the highest volume) then
the referece volume won't be changed and hence new streams will be set
to hatever was the reference volume before.

> My apps are scaling fine, but here's the problem:  "main system
> volume" is meaningless.  I have no control over it, since Pulse will
> set it to whatever it wants.  There's no point in even changing it --
> I should just merely set the per-app volumes and let Pulse figure out
> what to do.

That's not true. Just set the sink volume to whatever you want. All
stream volumes are relative to that.

> I don't have my laptop plugged into a stereo system with a big volume
> knob that I can turn.  When I set the main volume to 80%, I want it to
> stay that way.  I don't want something like playing a YouTube video or
> playing a new CD to change the volume back to 100% or whatever it
> wants.

It seems you first set the sink volume to 80%, then set the stream
volume of youtube to 100%. This will then be remembered as "set
youtube to 125% of the sink volume".

> In essence, the user should be able to set the volume of any program
> he likes, and expect that the system will respect that.
> 
> One solution.
> 1.  When a new never-seen-before app is launched, Pulse defaults not
> to 100% but to the current system volume.

Which is what happens. We call that "reference volume" however.

> 2.  Pulse should never change the main system volume on its own.
> That's mine.

PA won't touch the reference volume. What it will do is touch the
virtual volume. 

> 3.  If I change the loudest App, then Pulse may change the main system
> volume to match.  But only because I did it; whenever an App starts on
> its own, Pulse matches it relative to the main system volume.

That's exactly what happens, with the exception that we apply it
relative to the 'refernce volume', not the 'virtual volume'.

> This, in fact, is the way Windows Vista behaves.  Pulse currently
> doesn't behave like Windows Vista:  nothing ever changes your main
> volume on Windows except you, or unless *you* change the highest
> volume app.

WHich is exactly what happens in PA. With the exception that we
save/restore the relative volume of each stream-

> It's also worth noting that System Sound Events are shown as an App in
> the Windows Vista list (unlike Pulse, where they are separate) --

Uh? pavucontrol shows system events as a slider on the "Playback" tab
where all the other pp streams are shown too.

If you are speaking of g-v-c, please file a bug against gnome-media.

I think the big confusion stems from the fact that PA distuingishes
"reference" and "virtual" sink volumes, but this distinction is not
really visible in the UI which only shows the latter, but can be used
to control the former.

To clear this a bit up, here's another try at an explanation:

1. The reference volume of a sink is the one all relative stream
volumes use as base. It is never changed automatically -- it is only
changed by user intervention, such as changing the sink volume slider
in the UI. 

2. The virtual volume of a sink is the maximum of all stream volumes
attached to the sink. It is as such always calculated dynamically and
can only be controlled by changing stream volumes.

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.

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 think the core problem is that it is impossible to figure out what
the user actually wants. When he increases a volume of a stream he
might A) want it a bit louder then whatever else is currently playing
and would be pissed off if the other stream would get louder at the
same time or B) want it a bit louder because everything that's playing
is just too silent and he would be pissed off if only one stream would
get louder and not all.

And this problem then spills into everything we have: into the
persistance logic, into the UIs (where we don't know what slider to
show to the user) and so on.

The only option we have is probably to make a clear decision and
accept that it might appear unintuitive to some.

Lennart

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