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
