I am looking into this bug and there are serval ways of solving this.

1) On startup checking if vol = 0 (seen that is what mute is all about
anyway) and if this is true go into mute state 

now this has a sub problem and that is that the applet indicates
the volume of 0% so what i could do is make it 100% in the applet
and then mute it.

2) Use a gconf key which saves the mute / volume level state and
sets this on startup. However i am not totally sure if we want to
force the volume... (like in if the user changed the volume level
and you suddenly force it up to the old setting)


I would really like to have a quick reply on this so i can start
fixing it. At the moment i am trying solusion 1 but if you guys rather
go for 2 please let me know

Created attachment 9986 [details] [review]
Probably not the right way of fixing this but have a look at it and give me comments

This is the when volume is 0% at startup go into mute mode
and leave volume at 0% version.

Created attachment 9987 [details] [review]
The if volume is 0 set mute and volume 100% version

Sorry for keep spamming you guys.. i think a gconf version
would be the best solution but then we also have 2 choices

1) Save both mute and volume settings in gconf and set them at
the start of the mixer applet

2) Save both mute and volume settings and when left in a mute
state next time check if the volume is still 0% if so
set muted and the old volume.

Ooh, PATCH. Thanks, Dennis.

Yep A patch but probably not the way we want it eventually .. 
i would like kevinv to look at my suggestions ..

I would like to see the mute state and volume saved and restored
regardless of what the volume is set at during login. The reasoning is
that on a multi-user machine, two different users can have two
different volume and mute preferences.

Please can someone with more indept knowledge help me out
and tell me how i should handle this.

If someone comes up with a "You should do this and this" list
i start working on it right away.

Anyone got any good suggestions for Dennis?

If the sound is muted, make it muted when you come back and the soundlevel is the same (ie. 0). Otherwise leave the current sound settings.

This isn't the kind of thing you want to do complicated. You only need to keep the current muted state in gconf.

Yep, Hadess is probably 100% right. It indeed isn't the thing that
should be done complicated and 100% fail proof :). Anyway it has
been a while ago since i've been looking into this. So i could use
some clue about which branch i should check out and start hacking on.

Thanks for the suggestion hadess!

Dennis: do this for HEAD. 

A question I have is should we save the volume and mute settings. Why
just save the mute settings?

Kevin sorry i don't exactly understand you could you explain ?

Another side note: I was thinking about the effect it would have
to simply set mute state when volume is 0. When you unmute the volume
will still be 0 because that is the current sound level so maybe a
way to get around this is when muted save the old volume as a gconf
string and then when the applets comes up again it checks if the
volume is 0. If so set muted and when unmuted set the old volume

How about when the user selects unmute then put the volume to 1? So this: 

The user slides to zero - the applet mutes
The user selectes unmute - the applet sets the volume to 1
The user slides up past zero - the applet unmutes

Dennis: I was thinking of whether we should restore the volume on
startup if we will restore the mute state.

*** Bug 103265 has been marked as a duplicate of this bug. ***

In Solaris, if the volume is muted from the mixer applet instead
of reducing the volume to 0, ainfo.output_muted is set in the audio
info structure similarly when it is unmuted ainfo.output_muted is
unset. This solves the problem of mixer applet losing the mute status
when removed and added again. I have sumitted a patch to bug 105724
which also solves this problem. Thanks.

*** This bug has been marked as a duplicate of 61253 ***