What version of gnome-applets is this? This is really meant to be fixed up in 2.10.

This can't be fixed. Muting in ALSA is done by setting the volume to zero. On
most soundcards, a 'mute' setting does not exist, because no matter what volume
you set, we keep telling ALSA that the volume is zero, because that is the only
way to enfore the 'mute' state. Therefore, the volume on the other control is
not changed.

Seriously, I'd love to fix this, but it requires me to dig into ALSA. At the
very least, the bug would be NOTGNOME.

The version is 2.10

Well, it seems like the thing is partialy working now. I guess one of those
updates from ubuntu fixed it. Changing volume in the applet now updates the
volume in the dialogue. But, synchronization between 2 dialogues is still
broken. Maybe (I realize this is only partial fix) only one volume dialogue
should be permitted to be open at a time?

Also, how about this: 
1) if the mute is turned ON, drop the volume bar to 0
2) if the mute is turned OFF, get the volume back to original value
3) if the volume is changed while mute is ON, turn the mute OFF, forget the
saved original volume.

I played with the volume some more, and the control seems to be inconsistant in
behavior:

1) bringing volume on applet to 0 turns mute ON
2) but, bringing volume to 0 in dialoge *does not* turns mute ON
3) unlocking channels and lowering them separately to 0 *does* *sometimes* turns
mute ON. 
4) take the volume to 0 using applet. now unmute it using button in dialogue.
the volume in applet goes up a bit on its own.
5) try taking volume in the applet down fast. as soon as it hits 0, the volume
in dialogue, which usually lags behind, stops short of reaching zero

... People are going to hate me for this.

For most of ALSA's controls, mute means 0. That is reality. Anything that we
implement has to take that into account. Or we need to fix ALSA.

Now, there's indeed theory-cases where it doesn't work out. However, we
primarily look at the common practical use cases. Those are:
* turn volume up/down a bit to in-/decrease volume
* mute/unmute to turn on/off volume
all design decisions are based on the convention that those actions are most
important. Everything else is important, but secondarily.

Now, we get update notifications of the mute state if the hardware supports it
(N/A here) and of the volume. If the update notification of the volume is zero,
this may mean two things: A) the volume was set to zero, or B) the track was
muted. Since B) is more common w.r.t. the use cases, we use that as assumption.

With that in mind, now go back to all examples you've validly complained about.
You'll notice that they're all an effect of this. Someone needs to fix ALSA to
get over it. And OSS. And all other mixer applications out there. It's just a
no-go, really. This is about as good as it gets. It's not perfect, but it's good
enough. Yes, they are bugs, but they cannot easily be fixed.

Your suggestions in comment #3 have been suggested before, and have actually
been implemented for a while, but the usability people (i.e. Seth) preferred the
current status, which is what I've implemented. I think I mostly agree with them.

In its current status, g-v-c and g-v-a interact mostly correctly with other
applications, and interact well with each other. I think that's worth a lot more
than unusable but perfect behaviour.

Ronald, thanks for taking time to answer me in length.
I don't think I agree with Seth about #3. Having something as (seemingly) simple
as sound control behave unpredictably can be very annoying, and that is a
usability problem on it's own. 
But eventually it doesn't really matter, since as you said, ALSA is the root of
all evil here. Hopefully ALSA people fix it sometimes.

I will probably end up fixing ALSA myself at some point... :-(.

Anyway, then we still have the issue of Sun and OSS (BSD), but at least the
Linux side then works as it should.