[lang]

Present Perfect

Personal
Projects
Packages
Patches
Presents
Linux

Picture Gallery
Present Perfect

Volume control in GNOME

Filed under: GNOME — Thomas @ 13:18

2004-09-06
13:18

Ronald asked for some input on the volume applet, and since Seth gave him some advice that I consider bad, I'm posting my thoughts here so I don't have to repeat myself too often.

My personal interpretation of usability is "do the right thing for the user automatically, and make other functionality as easily possible as can be without compromising the first goal." This might be a wrong interpretation, so clue me in if it is. But to me, this means that it's the software's/developer's responsibility of making the user do the right thing.

Now, the right thing for usability is, for most of GNOME, UI-driven, but sometimes also task-driven. In the case of the mixer applet, there's another factor that comes into play, and that is "how audio works".

Seth argues that there should be a slider that controls all of the inputs *at the same time*. While this might be nice UI-wise, it is the perfect way of getting really bad audio. And that's because it conflicts with common sense principles in audio.

Let's start with a ground rule: at any time you should only activate/turn up the volume for an input that's actually usefully contributing to the signal. This means you shouldn't have the CD volume up if you don't have a CD playing. The reason for this is simple: it adds noise. It decreases the quality of your sound. Imagine that I have my phone line jacked into my SB Live, and the phone volume would be on all the time - it wouldn't take me long to throw out my PC or switch to a sensible solution instead.

A second working principle is that the "master" volume is in fact quite different from all the others, so it's a bad idea to change master *by the same amount* as all others that are mixed into master. The practice is simple - all levels beside master or to be set so that a) all inputs sound about equally loud for normal use and b) while respecting (a), each of them is set as high as possible without actually going into distortion. After that, you can use your "master" volume control to control your output volume for everything combined at any given time.

A third rule, quite succintly parodied in Spinal Tap, is: don't turn the volume up all the way. This is a very difficult principle to get across to ANY person that doesn't really know how audio works. I cannot count all of the times anymore that I went to some party or to someone's home and the volume is cranked up ALL THE WAY because otherwise it's not loud enough. At some point, turning the volume knob only gives you more distortion, making the output sound louder indeed, but also makes it suck incredibly for people that actually like listening to music. You'll quickly notice that turning it back a few makes it sound a lot more pleasant without making it that much more silent.

The principle here is simple: If you can't get it loud enough, buy new equipment. There is really nothing else you can do here.

Now, I hope I convinced you that having "one slider changing all others at the same time" is a bad idea. And I'm not saying that the solution is that the user should know all these rules. But I am saying that anyone that writes the code for this, or offers accessibility advise on this, is required to understand these rules in order to come up with a good UI.

So I'll offer my suggestions on how I think this should translate to the platform and applications.

a) The platform should have a wizard that helps the user set decent volume levels for all the input tracks. The goal is to make sure that all the input tracks have relatively the same volume level for normal inputs without distorting.
Technically, this can be implemented by having the software monitor the level by monitoring the master output level, if the soundcard allows you to. If not, the user should do it by ear. The user should provide some audio on each of the sources you want to calibrate; ie. play a CD, talk into the microphone, ... The software should mute/unmute each track as the wizard switches between them, allowing the user to switch between all of them until the levels are all more or less the same.

If the level controls are linear (I'm not sure if this is true for most soundcards, but it would make sense if they were), then the thing you want to store in your backend is their relative positions towards eachother. This way, you can nudge them all up or down a little if you notice distortion in either of them.

b) When this is done, the mixer applet should only export the master volume level. It would be nice if you could mark a distortion threshold somehow, so that the mixer applet makes it harder to cross it. Typically, the sliders just allow you to go from 0 to 100, where 100 means "sounds like crap" and 50 already means "you can only hear this if you're a ten day old baby".

c) applications should unmute the input controls they actually produce signal on, and remute them when they stop, and nobody else is using it. So the information on what application is using what control should be shared.
In practice, this means that the CD playback level is muted until an application starts up that plays CD's through the cable connecting your sound card to to the CD player. When it exits, and it is the last CD using application to exit, it should mute it again. Preferably this would be done through library hooks, of course. And, the volume control preference program would also be a "user" of this track if the user decided to override global settings and wants to hear the CD always.
Same goes for your phone application, or your music player.

So, this in my opinion the correct way to translate the technical domain of "how it works on the system level" to "how you give the best user experience". When all these parts are implemented correctly, the user experience will be that it "just works" and that "it doesn't sound like crap".

Codewise, it would mean:
a) there needs to be a wizard to set up sound levels correctly
b) there needs to be a daemon tracking the state of applications and their use of mixer channels; or some other way to exchange this information

I'm interested in what people think about this, and if there's enough interest to actually make this happen for GNOME 2.10 ?

2 Comments

No comments yet.

RSS feed for comments on this post. TrackBack URL

Sorry, the comment form is closed at this time.

picture