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
