ke, 2010-01-06 kello 11:17 +0000, Colin Guthrie kirjoitti: > Still early days but: > http://colin.guthr.ie/2010/01/mix-it-up/ > > Have fun. Nice work! I was going to write a comment to that blog entry, but it grew long and became off-topic. So I decided to start a new thread here. Regarding the blog entry, I have two points: 1. I suggest you open the stream volume tab by default. That makes sure that if the user changes the device volume, it's because he or she makes the explicit decision that the device volume should be changed instead of the stream volume. 2. You seemed to think that after jack sensing support, users would only need to change ports to enable/disable extra amplification (or other option). But if multiple ports have speakers/mics connected to them, jack sensing doesn't help - the user still has to have the possibility to choose the port manually. What made my original comment so long was the explanation for point 1, which is the main topic of this mail. The explanation follows: I have recently formed a belief that in the vast majority of cases where the user wants to tweak the volume, the best choice is to tweak the stream volume, as opposed to the device volume. Device volume changing makes usually sense only when the listening context changes in some way: if there's some temporary background noise in your environment, you may want to turn the global volume up, or if there are other people in the same room, you may want to turn the global volume down not to annoy them too much. The problem is that you have to consistently use the device volume whenever the context changes. If you sometimes use the device volume and sometimes the stream volume, pulseaudio loses track of what you want and applications will often have the wrong volume when they start up (I hope you understand without further explanation why that happens). And I think it's very probable that you don't remember to always use the device volume when you should. The solution is to ignore the device volume and always change stream volumes. Now, when the listening context changes, using the stream volumes has its problems too: if you need many programs that use sound, you will have change their volumes separately. But I believe that usually the context change is temporary, and there is some "main context" where most of the programs are used. In the temporary context only one or few programs are needed for the duration of the context, so changing one stream volume is usually enough. When adopting the "stream volume only" approach to volume control, using the simple hardware controls (+vol and -vol buttons on a laptop, or a volume dial on a multimedia keyboard) becomes more useful, because they pretty much always do the right thing - change the volume of the currently playing application(s), and nothing else. At least on my desktop the volume dial changes the sink volume, which is rarely the appropriate course of action, as I have explained. These simple controls that only convey the meanings "increase the volume" and "decrease the volume" require some extra logic in software to guess what the user wants. I think this logic should be in pulseaudio. It is probably possible to do this without touching the core, ie. just creating a new module should be enough. The module - let's call it module-dwim - would provide an extension that would be used by volume applets and those pieces of software that handle the hardware volume control events. The extension would contain three functions: IncreaseVolume, DecreaseVolume and ToggleMute. The logic for ToggleMute: - If all sinks are unmuted, mute all sinks. - If all sinks are muted, unmute all sinks. - If only some sinks are muted, then A) if there are no active streams, mute all sinks. B) if there are active streams, of which at least some output to unmuted sinks, mute all sinks. C) otherwise unmute all sinks. The logic for IncreaseVolume and DecreaseVolume: - If no streams are active, adjust the event role volume. - If only one stream is active, adjust its role volume. - If multiple streams are active, adjust them all with the same amount of decibels. Adjusting the event role volume when no streams are active is clearly an non-obvious choice, and for this reason the UI should show a description of what was changed. That is also useful when multiple simultaneous streams are adjusted, and it should also give the user a hint of the underlying model: only these streams have their volume changed, nothing else. The information shown would come from pulseaudio as a response to the IncreaseVolume call. So, when I turn the volume dial on my keyboard one tick clockwise while listening to music and watching a movie (sorry, I couldn't think of any better scenario where multiple streams are active), in my model the volume of the louder stream is increased 5% and the volume of the quieter stream is increased by the same amount of decibels (pulseaudio doesn't map percentages to decibels linearly). Also an onscreen display is shown, which shows a two volume bars, which have titles "Music" and "Video". As an extra feature, the icons of Rhythmbox and Totem are shown next to the volume bars. If it happens that the computer didn't do what I meant (I wanted to change only the music volume), I turn the volume back down and either use the volume control widget in Rhythmbox, use the scroll wheel above the Rhythmbox tray icon or click the volume applet. If I choose to click the volume applet, it pops up a widget that contains sliders for all active streams, and also for event sounds. If this was combined with the per-output stream restoring, the UI for volume control just might be as good as possible. By the way, with the per-output stream restoring it might make sense to also include the sink name in the onscreen display that shows the stream name. So instead of just "Music", it would show "Music via M-Audio FastTrack Pro (Headphones)". That would again provide more hints about what really happens (but I guess it would really be too much information). Thanks for reading. -- Tanu Kaskinen
