[pulseaudio-discuss] Stream volumes as the universal volume adjustment method

[Lennart Poettering]

On Thu, 07.01.10 18:30, Tanu Kaskinen (tanuk at iki.fi) wrote:

> 2. You seemed to think that after jack sensing support, users would only
> need to change ports to enable/disable extra amplification (or other
> option). But if multiple ports have speakers/mics connected to them,
> jack sensing doesn't help - the user still has to have the possibility
> to choose the port manually.

Yes, this is correct. Jack sensing will give us a hint which ports
might be suitable, but the set of suitable ports might have more then
one element, in which case we are dependant on user input.

> What made my original comment so long was the explanation for point 1,
> which is the main topic of this mail. The explanation follows:
> 
> I have recently formed a belief that in the vast majority of cases where
> the user wants to tweak the volume, the best choice is to tweak the
> stream volume, as opposed to the device volume. 
> 
> Device volume changing makes usually sense only when the listening
> context changes in some way: if there's some temporary background noise
> in your environment, you may want to turn the global volume up, or if
> there are other people in the same room, you may want to turn the global
> volume down not to annoy them too much. The problem is that you have to
> consistently use the device volume whenever the context changes. If you
> sometimes use the device volume and sometimes the stream volume,
> pulseaudio loses track of what you want and applications will often have
> the wrong volume when they start up (I hope you understand without
> further explanation why that happens). And I think it's very probable
> that you don't remember to always use the device volume when you should.
> The solution is to ignore the device volume and always change stream
> volumes.

I tend to disagree.

I actually believe that device volume is more relevant that stream
volume. And this is why:

There are three reasons to turn the change volumes: A) the material
you play is too faint/loud because it was digitized that way and you
want to compensate for that. B) your surrounding is too silent/loud
maybe becuase you stepped on a train or a plain or out of it or
someone wants to talk to you or shuts up or suchlike C) You play two
things and want one thing louder then the other.

In cases A and C changing the stream volumes appears appropriate. In
case B it appears more appropriate to change device volume. Why?
because if we define "device volume" as a factor we apply to all
current and _future_ streams the same way, then this matches B, where
we want to do exactly that: change the volume of *all* current and
future streams, while in A and C we want to change just *one* existing
stream.

Now, why is B more relevant than A and C? 

Ideally, problem A would not exist because all media would have a
standardized normalized perceived loudness. Obviously and
unfortunately that is not the case, but it appears to me as if we
could actually fix this problem better than with manual volume
control. What I have in mind is having some code in PA that does a
subset of the replay gain algorithm do determine something like the
perceived loudness of a stream in some time window (and if the data
comes from gst we could even rely on the predetermined replay gain
from the ID3 tags or so). Anyway, regardless whether this problem is
fixed in PA or in a media player, I believe the fix for this is not
manual but automatic volume compensation in some way. (Though this
actually opens another can of worms because suddenly you might want to
configure event sound volumes relatively to the perceived loudness of
your music stream, and not to the "device" volume)

Case C you probably do very seldomly. You configure the loudness of
your event sounds in relation to your normal music once, and then you
leave it that way.

Leaves case B, which seems to be the common case. In latops, in
desktops and especially in mobile phones and suchlike. Your
environment changes. You need to adjust to that.

> When adopting the "stream volume only" approach to volume control, using
> the simple hardware controls (+vol and -vol buttons on a laptop, or a
> volume dial on a multimedia keyboard) becomes more useful, because they
> pretty much always do the right thing - change the volume of the
> currently playing application(s), and nothing else. At least on my
> desktop the volume dial changes the sink volume, which is rarely the
> appropriate course of action, as I have explained.

I do believe this is the wrong thing. Let's say I fly. I listen to
music and watch a flash movie. Due to the plane noise i turn both
stream volumes up. Arriving at the airport I go to the senators lounge
to work a little. I play some music and turn it down to annoy nobody
else. Then I watch another flash movie. It still is on plane volume
and blasts out my speakers. All the other senator card holders are
shocked and look at me in disgust. I feel ashamed, immediately stop
the flash movie. Try to fix the volume, but cannot, because your alg
only would change the active streams, and i stopped the flash
volume. So i start the flash movie again and am embarrassed a second
time. Due to repeated misbehaviour I am being kicked out of Lounge and
lose my senator card. Due to that I start drinking and gambling and a
month later I commit suicide, and it's all your algorithms fault! See!
q.e.d.

Anyway. Point is: when entering the lounge the user should be able to
simply lower the volume and then rest assured that all future streams
are influenced by this too. That's why I came up with the current
scheme, where the sink volume is something like the bracket the actual
stream volume will never go beyond.

> The logic for ToggleMute:
> 
> - If all sinks are unmuted, mute all sinks.
> 
> - If all sinks are muted, unmute all sinks.
>
> - If only some sinks are muted, then
>   A) if there are no active streams, mute all sinks.
>   B) if there are active streams, of which at least some output to
> unmuted sinks, mute all sinks.
>   C) otherwise unmute all sinks.

Having a global mute/unmute certainly does make sense, I
agree. However it's a bit weird too. Let's say I have a bt headset and
internal speakers. I am in that dreaded airport lounge again because
the airline wanted to give me a second chance after i sued them in the
US because my suicide attempt by eating gummi bears failed. So I am
listening to Beethoven 9th with the BT headset in the lounge. The
laptop speakers are muted, the BT headset is not. Temporarily i want
mute old Ludwig, so I press that key, all audio is turned off. Then I
want to unmute again and press that button again. Now both sinks would
get unmuted and because I use module-combine I blast the 9th into the
lounge again. Get kicked out again. Detained by the US government, due
to musical terrorism. I grow a beard and start to wear orange jump
suits, and never want to hear Beethoven again. What a loss! And it's
all your algorithm's fault! See! q.e.d.

Point is: we'd need a history or so here too. Kinda sucks.

> The logic for IncreaseVolume and DecreaseVolume:
> 
> - If no streams are active, adjust the event role volume.

This won't work. If the user wants to change the volume he definitely
wants to do so for all streams he will be playing shortly in addition
to those he is already playing.

> - If only one stream is active, adjust its role volume.
> 
> - If multiple streams are active, adjust them all with the same amount
> of decibels.

This is mostly what currently happens: sink volume changes are
equally applied to all all stream volumes. However both current *and*
future.

> By the way, with the per-output stream restoring it might make sense to
> also include the sink name in the onscreen display that shows the stream
> name. So instead of just "Music", it would show "Music via M-Audio
> FastTrack Pro (Headphones)". That would again provide more hints about
> what really happens (but I guess it would really be too much
> information).

I thought about this too. It might make sense to show the device
string in the streams line iff there is more than one device.  In that
case it is useful and otherwise the information is redundant.

Lennart

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