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

[Jan Braun]

Tanu Kaskinen schrob:
> > 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 :)

Sure, if I don't need per-application volume control, then "amixer sset
Master 2%+" is enough.

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

Yep, got that here. Still doesn't help with per-application volumes. :)

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

An "incoming email"-notification not waking my neighbors because I was
watching a youtube-video with extremely low sond levels is a pretty big
win.

> The problem
> with your model is that it takes mental effort to do it right: [...]
> 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: [...]

Well, it's easy to fail any rules if you have both per-app and hw
sliders, and don't think about what you're doing ;)
At least if you actually want to change different applications' volume
relative to each other.

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

Aha. So you propose/defend making the per-app volume sliders difficult
to change to prevent users shooting themselves in the foot?

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

After waking the neighbors, and then he'll not be able to understand the
rest of that video.

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

Well, of course. Ideally, every per-app and the hw volume are set to
good default values. You change them because that good song comes up (or
whatever), and after it's done, you change them back.
The only question is if you change the per-app volume or the hw volume.

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

That might help.

> 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

I don't think an applet can be convenient. Might be just me, though.

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

Well, in a console not, in a screen(1) it's e.g.
| bindkey -k F1 command -c audio
| bind -c audio 8 exec ...| xmms2 volume +10
and then <F11><8> raises my xmms2 volume.

> (But I do see that pulseaudio's command line tools could be improved.)

Yep, see below.

> > Anytime you present multimedia content with a beamer or the like.
> 
> 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?

Yep.

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

Ok.

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

Yep, something like that would be nice.
Also, pactl could use a higher-level interface. I'd like to be able to
say "pactl connect xmms2 via82xx" to switch xmms2's output to the input
of my via card. Currently it's "pactl move-sink-input 38 1" or
"pactl move-sink-input 38 alsa_output.pci-0000_00_11.5.analog-stereo".

> Many thanks for your input!

You're welcome.
    Jan
-- 
()  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/20100417/c6ebad15/attachment.pgp>