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

Jan Braun janbraun at gmx.de
Fri Apr 30 16:17:41 PDT 2010


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

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.

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

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

> 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]

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

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.
regards,
    Jan

[1] per-application volume restoration, easy device switching and power
savings are nice, but not enough to make up for the extra hassle from
incompatibilities. YMMV, obviously.
-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20100501/ef04f741/attachment.pgp>


More information about the pulseaudio-discuss mailing list