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

[Tanu Kaskinen]

Long mail again, sorry :(

On Sat, 2010-05-01 at 17:19 +0200, Jan Braun wrote:
> Tanu Kaskinen schrob:
> > In my view changing per-app volumes is not a common activity.
> 
> In my experience, it is. That's because our usage scenarios differ.
> Lennart's distinction in
> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-January/006334.html
> |A) material you play is too faint/loud because it was digitized that way
> |B) your surrounding is too silent/loud
> |C) You play two things and want one thing louder then the other
> is very helpful. I hope (and think; please speak up if you disagree)
> we all agree that A (in an ideal setup) and C (always) call for
> per-stream volume adjustment and B calls for device volume
> adjustment.[1]

As long as you're playing only one stream at a time, scenario A can be
handled equally well with the device volume and with the stream volume.
It does make more conceptual sense to use the stream volume for scenario
A, but as I keep saying, using the device volume makes physical volume
controls much more useful. And as soon as you create a habit of using
the physical volume controls for scenario A, using the stream volume
becomes a bad idea.

That makes scenario C the only case where per-stream volumes are really
useful.

> What we DON'T agree on is the importance of the different scenarios.
> Lennart finds that "case B [..] seems to be the common case" and "Case C
> you probably do very seldomly."
> My experience is A:very common, C:somewhat common, B:rarely.
> Joe User might (imho legitimately) have his own, diffferent view.
> 
> So now the interesting question is how do we handle (or not) these
> differences?
> My view is that there can't be a one-size-fits-all solution, and I
> want the tools to build my personally ideal setup.[2]
> Your personal/user view is "I want device volume easily accessible, and
> per-stream volume may be more remote".
> Your "desktop developer" view is "We need a simple, general solution
> that 'just works' for the majority of desktop users". And you then
> proceed to assume C is rare, and A can still be done with device volume,
> so you don't _need_ per-stream volume, thus your solution is "do
> everything with device volume".

This seems like a correct summary.

> [ I'm getting distracted by the thought below, and the mail is long
> enough already, so I'm stopping here and give you the chance to speak up
> if I was misrepresenting you: please do, I am merely trying to sum up the
> discussion so far in a constructive manner. ]
> 
> 
> I'd wager a media player developer's view would be something like "We
> provide per-stream volume control easily accessible embedded in our
> player, and the user probably has a keyboard knob for device volume, so
> what's the problem?" And I think that view has a lot of merit.

If it's not clear for the media player developer what's the problem,
then give her a link to this thread :)

> Actually, writing this I realize we may be on the wrong track: Why do we
> want to stop media player authors from embedding volume controls?
> The original reason, IIRC, was that writing good volume controls is
> hard and we think PA people would do a better job.
> Then there was the argument it'd be better to have all volume control to
> be centrally done.
> Well, I don't see the point in "centrally", so unless somebody steps up
> to defend that, I'll ignore it.

No, the original reason for proposing the slider removal was not that I
think "PA developers are better at writing volume controls than media
player developers", the original reason was simply that I (and sadly no
other PA developer so far) think that volume controls do more harm than
good in media players, and that a central volume applet is an adequate
replacement for whatever use cases the volume controls in media players
currently serve.

I promote central volume management because it doesn't have the same
problems as volume controls in media players. Of course it has its own
problems - that's the whole point of this discussion: which solution is
better?

> But wrt. writing better volume controls: I think the media player
> authors will do a better job of writing the UI part of a volume control
> than PA people can (after all, integrated UI tends to be better).

Maybe it tends to be better, but in this specific case I obviously think
that it's not. Another case for central management: somehow Skype UI
designers came to the conclusion that when using the Pulseaudio backend,
it's best to disable the device selection that is enabled for all(?)
other backends. Instead of providing that configuration option, Skype
tells the user to use the system's central sound configuration utility.

> So why not provide a nice API for them to hook into? One that tells them
> the various interesting things ("default volume", "100%", "maximum
> volume", whatever you think is needed to implement the perfect control)
> and lets them wonder about which key the user presses or how to display
> the current volume. Pitching "look, a 0-100 scale really isn't the best
> way to do volume adjustment, here's how you do it better" to media
> player authors surely sounds more promising than "you're not doing
> volume adjustment the way we prefer it's done, so please stop doing it
> altogether and let us handle it."

I don't see how the usual slider itself could be much improved. Well,
color coded sliders [1] would be an improvement, someone just needs to
write such UI elements. From API point of view, PA already offers
everything to make such colored sliders useful.

So the issue isn't that the slider semantics are wrong, the existence of
the slider is the problem.

> And if you're really sneaky, you can add a function "the user doesn't
> wish you to provide volume control at all" to that API, and if/when you
> manage to convince users that the PA volume control applet is all they
> want, you can remotely disable the embedded controls.

Hmm... this is similar to having an option in all programs to enable or
disable volume control. But this idea would make it easier for users to
centrally control all audio applications' UI. (I'm not sure what would
be the best place for such option - gnome apps use gconf, what about
kde? Is there a cross-desktop technology for storing common user
preferences, apart from a custom ~/.volumesliderrc file?)

Making this configurable is a compromise, which I'd like to avoid until
the discussion stops moving forward. I don't think we're there yet.

> Similarly, you could allow the users to centrally choose whether they
> want the embedded controls to affect the per-stream or the device volume,
> if you think that's a valid choice to make.

Yes, that could be possible too, although I don't really see the point,
because changing the slider behavior to control the device volume
doesn't really solve anything that removing the slider altogether
doesn't solve. But yes, if for whatever reason I couldn't configure the
sliders away, having the option to use the device volume instead of
stream volume would be better than nothing.

> > 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
> 
> :(
> I really do need to easily control per-app volumes. I'm afraid if I
> couldn't convince you so far, I'll have to give up on that front.

So far I've heard two problems that you would personally have with the
device centric volume control: too loud event sounds and the need to use
a voip application and a music player simultaneously. I got the
impression that the automatic event sound volume adjustment would be an
adequate solution to the first problem. For the second problem, I
believe that for a vast majority of people a sound applet like this
would be just fine:
http://img263.imageshack.us/img263/3403/volumeapplet.png

I think I've seen screenshots or mock-ups of a similar solution for
gnome-volume-control-applet, but at least on Debian the applet provides
just a single slider. And it seems[2] like Ubuntu's new "sound
indicator" doesn't provide much more. Conor, if you're reading, would
you like to comment on why Ubuntu's new volume applet should restrict
itself to show only one slider that might not even control the device
that is actually currently in use?

You've said that you're not happy if you can't do everything with a
keyboard. Changing the music player volume using keyboard only requires
you to switch to the player application (which, btw, isn't required if
you use the volume applet that I envisioned in that mock-up). I think
it's possible for Pulseaudio to figure out what's the application that
currently has the focus, so if you could tell PA, using scripted
hotkeys, to increase/decrease the currently active application's volume,
would that be a satisfactory solution? Or actually, if I've understood
correctly, you might be happy even with just an easier way to create
scripts that change the volume of some hard-coded application, so you
could configure dedicated hotkeys for controlling Mumble's stream
volume, for example?

If you're happy with these solutions, but you still have other use cases
that interfere with the device centric volume control model, please
tell. That's the way to convince me.

Oh, I almost forgot to explain some ideas behind that mock-up:

1) The topmost part shows all sinks that are currently used by some
application. If nothing is playing, then the default sink volume is
shown. Most of the time the user should adjust these volumes.

2) The active streams part is by default collapsed in order to push the
user to prefer the device volume over the stream volume in "scenario A"
cases. There are some exceptions to the collapse-by-default rule:

        a) Some sink is used by more than one application. This makes
        life easy in the voip-and-music case, and also in the gaming
        case, if the game isn't a full-screen game.

        b) Even if only one application is playing, it's still shown if
        the application's stream volume is not 100% relative to the sink
        volume. This is because most of time applications should play at
        100% volume relative to the sink volume, and when that's not the
        case, the user should be aware of that.

3) The volume applet shows only things that are needed for most common
sound adjustment cases. For complete control, the system specific "Sound
Preferences" application (e.g. pavucontrol) can be started from the
applet.

4) The applet window shouldn't be very big and complex, which is why
source volumes aren't shown. Maybe they should, I don't know.

Regarding the exception 2b, I feel that it might not be the best choice
to expose the full hw range in stream volumes like is done now, because
it isn't so easy to check whether a stream has "normal" volume, or set
the stream volume to "normal". I think the stream volume scale should be
relative to the current device reference volume. I know that it's
exactly how things used to be, so maybe this is blasphemy. The old
behavior can be restored by disabling flat volumes, but then the other,
unrelated benefits (i.e. maximization of analog amplifier use) of the
flat volumes are not available.

> But can you accept that I (and by extension probably a lot of other
> people not on this list) _feel_ I need this feature?

Sure, and I do my best to free you from your feelings :)

> And that telling me "you don't, you should be fine with device volume"
> doesn't help?

Yes, and that's why I try to back up my opinions with rational
arguments.

> And in particular that trying to remove embedded volume controls (which
> currently do provide easy access to per-app volume settings) without
> providing adequate* replacement will be seen as a severe regression?
> 
> *)adequate in my view, not yours

Yes, and I'll try to provide those adequate, although possibly currently
non-existing, replacements. That means that before really pushing for
volume control removals, I'll probably implement those missing
replacements (assuming that my views get wider acceptance from the
Pulseaudio community, which doesn't look too promising currently).

> > and this is my second proposal to solve the underlying problem of
> > users changing the wrong volume.
> 
> ==================================================================
> I think that's impossible to do within the constraints you've set.
> ==================================================================

That's certainly possible, but I'm not convinced yet.

> > 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.
> 
> Actually, voip programs for gaming have the additional problem that
> they need to present a minimally invasive UI, because the user interacts
> with a -presumably fullscreen- game. Hence that slider is a special
> challenge, and AFAIK no gaming voip does it, because it'd mean two more
> buttons they'd have to intercept away from the game. This is another
> place where I want to be able to script per-app-volume, btw.

Are you saying that the current voip solutions don't allow you to change
the volume from withing the game? So you have to switch to the desktop
environment if you want to change the voip volume? In that case a volume
applet should be at least as good an alternative.

> > 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.
> 
> Weren't you on a quest to abolish embedded volume controls rather than
> wishing for more? As I understand it, you just suggested a game should
> ideally have a volume control for the music player, but the music player
> should not have one for itself.

I assume switching to the normal desktop environment from a full-screen
game is cumbersome. In a full-screen game the volume applet isn't
available, so ideally it should have some replacement in its own UI.

> ====> voip while listening to music <====
> Damn, that's another one where I've to be prepared for the "Jan, you're
> insane" counter-argument. :) But honestly, I do this. On the pro side,
> it's really, undeniably, absolutely important to have per-app volume
> control if you do that, otherwise you'll (deservedly) get yelled at.

That's a fine use case, which I've commented earlier in this mail.

> Well, try to see it this way: Once you've got good scriptability,
> everyone can easily create their favourite UI, and maybe some random guy
> will happen to find the perfect "common computer user" UI you're looking
> for. And you didn't have to do anything but implement scripting support! ;)
> 
> As explained above, I won't be that guy. And the only way I can help
> you is by telling you why your proposal X (which doesn't include
> scripting support) is not adequate for me. Or by trying to dissuade you
> from the notion that there actually is a solution which works for your
> "common computer user".
> Both may not be help of a kind you want or appreciate as such, so please
> say "stop" when I should do so. :)

Both are exactly what I want. Thank you for keeping the constructive
criticism coming!

[1] http://pulseaudio.org/wiki/WritingVolumeControlUIs#Colouredvolumesliders
[2] https://wiki.ubuntu.com/SoundMenu

-- 
Tanu Kaskinen