[pulseaudio-discuss] Removing volume sliders from media player UIs

Sat May 1 01:11:50 PDT 2010

On Sat, 2010-05-01 at 01:17 +0200, Jan Braun wrote:
> Tanu Kaskinen schrob:
> > > Aha. So you propose/defend making the per-app volume sliders difficult
> > > to change to prevent users shooting themselves in the foot?
> > 
> > Yes. Well, just in order to avoid misunderstanding, I don't propose
> > making it "difficult", just significantly less convenient than changing
> > the device volume (i.e. changing per-app volumes would require
> > navigating to a "sound preferences" utility of some sort).
> 
> By that reasoning, the media players would be allowed to have a volume
> control for changing the device volume. (That's a very bad idea imho.)

I'm not forbidding or allowing here anything. I don't have that power.
I'm trying to build a convincing argument so that media player
programmers voluntarily change their UIs. You didn't say why you think
device volume in bad - I assume because you think that the natural user
expectation is that a volume slider in an application affects only that
application and no others. And I accept that argument, and that is why
I'm proposing getting rid of the sliders entirely instead of replacing
the per-app controls with device volume controls.

> And btw, I consider anything that involves the mouse too difficult for
> common usage. Hence your "sound preferences" utility is not an acceptable
> solution in my view.

In my view changing per-app volumes is not a common activity.

> > But if you use per-app volume, you can't use the (hypothetical) volume
> > slider on your keyboard, which is a good reason to use device volume
> > only.
> 
> Well, this is why I requested a scriptable way to adjust the per-stream
> volume of the current application: Then the (hypothetical) volume slider
> on my keyboard could adjust per-application volumes.

You still haven't convinced me to believe that you actually need to
script your hotkeys or whatever to control per-app volumes - scripting
them to control the device volume should work ok for you (unless the too
loud event sounds are too big problem, but that can be fixed with "smart
event volumes").

Anyway, the request for better scriptability has been noted.

> > I usually use the volume dial on my keyboard, but it has happened that I
> > didn't quite think what I was doing and I changed the stream volume
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > using the volume slider in Rhythmbox, causing some minor but unnecessary
> > inconvenience - the conclusion: a conveniently available stream volume
> > slider in Rhythmbox is a bad thing,
> 
> My conclusion is different. ;)
> I want the tools to shoot myself in the foot, and I think giving them to
> users is one of the big strengths of unix. Please stick to that principle.

I don't want to have to think about what to do when the volume is not
right. If the volume sliders in applications and the volume dial on my
keyboard do different things, I have to think.

If you think that the volume dial on a keyboard should control per-app
volumes, that idea has been shot down. I proposed exactly that a while
ago, and this is my second proposal to solve the underlying problem of
users changing the wrong volume. The thread for my previous proposal can
be found here:
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-January/006247.html

> > in addition to being mostly
> > redundant (it's only needed when the relative volume to other apps needs
> > to be changed, which mostly (only?) means situations where two
> > applications are playing simultaneously).
> 
> If that situation is rare, there's not much point in PA, from my user's
> POV.[1]

Then I guess there's not much point in PA. For you. Which is fine. PA is
built to serve other use cases than yours (although judging from your
footnote, it seems that you do find useful features in PA in addition to
the per-application volumes, and the problem of incompatibility seems to
be getting smaller all the time).

> > If I've understood correctly, too loud event sounds are your only major
> > gripe with my proposal. If so, I guess this "smart event volume" is some
> > kind of a priority for me, in case it isn't for Lennart.
> 
> Too loud event sounds are my example for showing you why trying to do
> everything with the hw volume is wrong (if you have more than one audio
> source playing simultaneously).
> If "event sounds" is not sufficient for you or you think you can avoid
> the problem by treating them specially, consider voip + gaming:
> The other person moves their mic or shouts at someone in their room. You
> want to adjust the voip volume, but the game volume must stay the same.

Thank you, use cases are the best way to point out problems in
proposals!

If the voip program is targeted solely at use while gaming (I think
there are such programs, but I'm not a gamer myself), then a slider in
the voip program that controls the voip volume only makes a lot of
sense. That's because such programs are mostly run simultaneously with
other sound sources, and in those situations it's obvious that changing
the device volume is not the right thing to do if only one stream needs
adjustment.

If the voip program is targeted for general use (meaning that calls with
nothing else playing simultaneusly are common), the volume slider
probably causes the same problems as in media players.

I think in a perfect world games would integrate with the audio system
so that they would themselves offer the voip slider (and the music
slider too, btw - I guess it's somewhat common to have a music player
running at the same time with playing a game?), so the voip programs
wouldn't need the slider themselves, but that seems extremely unlikely
to become reality. Since having an easy way to control the voip volume
while playing a game seems like an important thing, does that mean that
all voip programs should have an output stream volume control slider?
Maybe it does mean that, and maybe this problem can't be solved for voip
programs as well as for media players.

Hmm... The "music while gaming" scenario can cause a situation where the
music is set to a low level, and after finishing the game it's not
obvious what should be done to rise the volume to the normal level
again. It's easy to increase the device volume, but that's exactly the
way to get annoying surprises: the volume has been decreased using the
stream volume, and increased using the device volume. Now all other
programs blast their sound too loud, because the device volume has been
increased from its normal level.

I don't think I have any good solutions to that problem. Arguably
removing the stream volume slider from the music player makes the
situation worse (but having the slider desn't completely remove the
problem either). Would it make sense to treat the presence of streams
with role "game" as a separate context for stream volumes? So when
stream volumes are adjusted while playing a game, the volumes are only
used while the game is running, and the old stream volumes are
automatically restored when the game streams are shut down. When
starting the game again, the stream volumes for the "game context" are
again automatically restored.

> That said, event sounds is probably the most prominent case for me. But
> please don't use that as an excuse to band-aid around the problem, which
> is lack of easy scriptability in PA.

Hmm, so you are seeing the lack of scriptability as the main problem?
Because it prevents you from scripting hotkeys to control the per-app
volumes? If you still think that you want to control per-app volumes
after reading this message, and after reading the discussion of my
previous proposal, then yes, I can see why you think that lack of
scriptability is the main problem. But personally I think this from the
common computer user's POV, who certainly won't script anything, so I
see things differently.

-- 
Tanu