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

[Tanu Kaskinen]

ke, 2010-01-06 kello 11:17 +0000, Colin Guthrie kirjoitti:
> Still early days but:
>  http://colin.guthr.ie/2010/01/mix-it-up/
> 
> Have fun.

Nice work!

I was going to write a comment to that blog entry, but it grew long and
became off-topic. So I decided to start a new thread here.

Regarding the blog entry, I have two points:

1. I suggest you open the stream volume tab by default. That makes sure
that if the user changes the device volume, it's because he or she makes
the explicit decision that the device volume should be changed instead
of the stream volume.

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.

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.

Now, when the listening context changes, using the stream volumes has
its problems too: if you need many programs that use sound, you will
have change their volumes separately. But I believe that usually the
context change is temporary, and there is some "main context" where most
of the programs are used. In the temporary context only one or few
programs are needed for the duration of the context, so changing one
stream volume is usually enough.

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.

These simple controls that only convey the meanings "increase the
volume" and "decrease the volume" require some extra logic in software
to guess what the user wants. I think this logic should be in
pulseaudio. It is probably possible to do this without touching the
core, ie. just creating a new module should be enough. The module -
let's call it module-dwim - would provide an extension that would be
used by volume applets and those pieces of software that handle the
hardware volume control events. The extension would contain three
functions: IncreaseVolume, DecreaseVolume and ToggleMute.

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.

The logic for IncreaseVolume and DecreaseVolume:

- If no streams are active, adjust the event role volume.

- If only one stream is active, adjust its role volume.

- If multiple streams are active, adjust them all with the same amount
of decibels.

Adjusting the event role volume when no streams are active is clearly an
non-obvious choice, and for this reason the UI should show a description
of what was changed. That is also useful when multiple simultaneous
streams are adjusted, and it should also give the user a hint of the
underlying model: only these streams have their volume changed, nothing
else. The information shown would come from pulseaudio as a response to
the IncreaseVolume call.

So, when I turn the volume dial on my keyboard one tick clockwise while
listening to music and watching a movie (sorry, I couldn't think of any
better scenario where multiple streams are active), in my model the
volume of the louder stream is increased 5% and the volume of the
quieter stream is increased by the same amount of decibels (pulseaudio
doesn't map percentages to decibels linearly). Also an onscreen display
is shown, which shows a two volume bars, which have titles "Music" and
"Video". As an extra feature, the icons of Rhythmbox and Totem are shown
next to the volume bars.

If it happens that the computer didn't do what I meant (I wanted to
change only the music volume), I turn the volume back down and either
use the volume control widget in Rhythmbox, use the scroll wheel above
the Rhythmbox tray icon or click the volume applet. If I choose to click
the volume applet, it pops up a widget that contains sliders for all
active streams, and also for event sounds.

If this was combined with the per-output stream restoring, the UI for
volume control just might be as good as possible.

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

Thanks for reading.

-- 
Tanu Kaskinen