[pulseaudio-discuss] Standardising on the amount of software amplification is presented to the user

[Tanu Kaskinen]

On Fri, 2010-04-16 at 21:04 +0200, Jan Braun wrote:
> Tanu Kaskinen schrob:
> > On Wed, 2010-04-14 at 10:18 +0100, Colin Guthrie wrote:
> > > 'Twas brillig, and Tanu Kaskinen at 13/04/10 20:42 did gyre and gimble:
> > > > Solution: throw away volume sliders in applications, and promote
> > > > centralized volume management with volume applets and hardware controls.
> > 
> > About b): if you're talking about the development effort of removing the
> > sliders, I don't think it's really that much work. But I think volume
> > applets and hardware volume control handler software aren't as good as
> > they could be, and they really should be good if they're to be the only
> > way of changing volume in most cases (in addition to pavucontrol and
> > other such applications that really are too clumsy for everyday use).
> > 
> > But do even we, the pulseaudio community, agree on this?
> 
> As long as there's no way to change the volume of "the current
> application" via the command line (so I can teach it to my window
> manager), I most certainly disagree. And yes, I do need per-application
> volume control (or think I do, see below).

Your window manager doesn't need to know the current application,
because you can teach it to control the device volume. So I still think
you don't need per-application volume control, see below :)

> > You can toggle fullscreen by pressing F, right? I don't personally think
> > that switching temporarily to windowed mode and using the volume applet
> > is too awkward.
> 
> It assuredly is for me. Volume control (or any important functionality)
> needs to be within easy reach, i.e. 2 keypresses max. The 5+ you suggest
> (includes switching back) is much too cumbersome.

For me it's either 1 or 2 or 3 keypresses (turning volume one notch up
or down), depending on what counts as a keypress and whether I use the
hardware volume dial on my keyboard or the volume applet with mouse.
With the volume dial I only need one touch to turn the dial, which is
perfect. If my keyboard didn't have the dial, I'd need to use the volume
applet, which would mean pressing F, moving mouse over the applet,
rolling the mouse scroll wheel and finally pressing F again.

If you don't have a hardware volume control like my volume dial
available, and you're capable of configuring the window manager to do
something with key combinations, I guess programming a key combination
to turn the device volume up or down would be easier than mousing
around.

> > Besides, changing the stream volume is still the wrong
> > thing to do (except in the rare occurrence when you actually do want to
> > change the volume relative to other apps).
> 
> How's that rare? Most of my touching volume sliders is caused by playing
> media that's not properly normalized/replaygained, or me wanting to
> listen to it at above/below normal level. If I did that with the master
> volume, I'd move my email/IM notification sounds as well. Or am I somehow
> mistaken in using the master volume as the adjust-for-ambient-noise-slider,
> and adjusting everything else per-stream to comfortable levels?

If your model works for you, then that's great. If you do it right, you
have to change the volume as often as with the device-volume-only model.
So even if you're doing it right, I believe you don't actually win
anything over those who use the device-volume-only model. The problem
with your model is that it takes mental effort to do it right: when you
notice the volume is wrong, you have to first think whether it's an
ambient noise problem or an application specific problem. When using
device volume for fixing normalization issues and "good song
issues" (where the song is too good to be played with normal level) the
reflex is the same as with the ambient noise issues - no need to think.

If a user has hardware volume dials or buttons and applications also
have their own volume sliders, it's really easy to fail to obey your
rules of volume adjustment: if the user uses the hardware controls to
play a song louder, that changes the device volume. And that means that
now every future stream is louder than before. The good song ends, and
the user doesn't think and he uses the application volume slider, which
controls the stream volume. Now the music player plays again at the
normal level, but all other applications are too loud. Either the user
uses the volume slider in each of those applications, which means fixing
the problem many times, or the user fixes the problem with the hardware
controls, which is otherwise good, but now the music player is too
quiet.

I believe most users haven't thought the concepts of device volume and
stream volume to begin with, so they don't know the rules that you know,
and therefore making wrong choices is very common if both the device and
the stream volumes are easy to change.

(I think it should be noted, though, that I don't remember hearing
complaints about this situation we currently have, so my beliefs are
only a theory based on reasoning, without empirical proof. All I know is
that I've been slightly irritated after I've changed the stream volume
when device volume would have been more appropriate.)

Compare that with the no-application-sliders case: the user uses always
the hardware controls, or alternatively the volume applet. Both of those
control the device volume. Now when the music player plays a good song,
the user turns the device volume up. Again, this messes up the volumes
of all other applications. But, this will be fixed the first time the
user notices too loud volume - he will again adjust the device volume.
Doing this one adjustment fixes it for all applications. Note that even
managing to do your model right doesn't win anything: as soon as the
good song stops playing, you still need to lower the loud volume in the
music player.

The notification sound issue may be solved in the future by making event
sound level's relative to the actual current sound level. That is, if
you play badly normalized stuff (too quiet), pulseaudio knows this and
plays event sounds quietly too.

> > Is mplayer any different from
> > e.g. Totem in this regard, btw? The lack of a gui doesn't seem relevant,
> > except when listening to music in the console while trying to fix X, in
> > which case volume control in mplayer makes a lot of sense. But even then
> > I think controlling the device volume would be more appropriate.
> 
> How's being in X or not relevant? ;) If you want to stop applications
> from bringing their own volume controls, you MUST provide an easily
> scriptable volume control interface. Which has no reason to require X.

Being in X is relevant because there you can have a convenient volume
applet in case you don't have the even more convenient hardware controls
(can those be somehow used in the console, btw?). I don't see how an
easily scriptable volume control interface would make changing volume in
a console comparable to in-application volume control. (But I do see
that pulseaudio's command line tools could be improved.)

> > Can you give some examples of the other use cases? I'm sure there are
> > such cases, but none comes to my mind right now.
> 
> Anytime you present multimedia content with a beamer or the like. You
> don't want to present the volume control applet you happen to use. You
> want your presentation going on and a minimal user interface for
> adjusting the sound, ideally unnoticed by everyone else.

Dedicated hardware volume controls work in this case, right? Or in
absence of those, using a basic keyboard with manually configured
keybindings for controlling the volume?

> So the way forward should probably be:
> 1) Educate app authors about how to write _good_ embedded volume
>    controls.
> 2) Get better external volume control programs.
> [time passses]
> 3) Convice app authors their embedded controls aren't necessary anymore.
> 
> ...particularly as 3) should become a lot easier after 2) is achieved.

I agree. If we get a consensus here, I don't see anything wrong with
making the overall goal known already today, though.

Do you have any specific visions for improved scriptability? I think
there should be a command that would say this to pulseaudio: "please
turn the volume up one step, and no, I don't care what the current
volume is or what device is currently used, and I trust you to choose a
sensible step size." And a similar command for turning the volume down
too :)

Many thanks for your input!

-- 
Tanu Kaskinen