Fix the audio mute button broken issue.

Fix several audio issues:
1. Audio button on ash tray UI does not work when user toggles it.
2. On ash tray bubble, if audio is muted, when user moves slider, audio is not unmuted.
3. Change CrasAudioHandler to update audio state, preference and notify observers for audio state change when user call CrasAudioHandler APIs to change the audio state, not when the dbus signals are received.
4. Move the code for adjusting unmute output volume to minimum unmute level out of SetOutputMute, and it is up to user to decide if they can call AdjustOutputVolumeToAudibleLevel to adjust the volume.
5. This also make the volume bubble shows up each time user presses mute, volume up, volume down button even if there is no audio state changes.

BUG=242549, 242964
TBR=jamescook@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=202334

[rkc, 2013-05-24 20:30:16]

https://codereview.chromium.org/15927004/diff/4001/chromeos/audio/cras_audio_...
File chromeos/audio/cras_audio_handler.cc (right):

https://codereview.chromium.org/15927004/diff/4001/chromeos/audio/cras_audio_...
chromeos/audio/cras_audio_handler.cc:217: bool 
CrasAudioHandler::SetOutputMuteInternal(bool mute_on) {
Nit: Move this down to near SetInputMuteInternal to match the order in the
header file.

https://codereview.chromium.org/15927004/diff/4001/chromeos/audio/cras_audio_...
chromeos/audio/cras_audio_handler.cc:379: input_mute_on_ = kPrefMuteOff;
This else block is redundant. The GetMuteValue and GetVolumeGainValue will
return the default values if we don't have a saved value for the device we're
checking.

We also should put a DCHECK here - there should never be a situation where we
don't actually have an active node id.

https://codereview.chromium.org/15927004/diff/4001/chromeos/audio/cras_audio_...
chromeos/audio/cras_audio_handler.cc:466: SetOutputMuteInternal(true);
What happens if output mute is locked? We still want to be able to mute when
we're doing a switch.

[jennyz, 2013-05-24 21:23:49]

https://codereview.chromium.org/15927004/diff/4001/chromeos/audio/cras_audio_...
File chromeos/audio/cras_audio_handler.cc (right):

https://codereview.chromium.org/15927004/diff/4001/chromeos/audio/cras_audio_...
chromeos/audio/cras_audio_handler.cc:217: bool 
CrasAudioHandler::SetOutputMuteInternal(bool mute_on) {
On 2013/05/24 20:30:16, Rahul Chaturvedi wrote:
> Nit: Move this down to near SetInputMuteInternal to match the order in the
> header file.

Done.

https://codereview.chromium.org/15927004/diff/4001/chromeos/audio/cras_audio_...
chromeos/audio/cras_audio_handler.cc:379: input_mute_on_ = kPrefMuteOff;
On 2013/05/24 20:30:16, Rahul Chaturvedi wrote:
> This else block is redundant. The GetMuteValue and GetVolumeGainValue will
> return the default values if we don't have a saved value for the device we're
> checking.
> 
> We also should put a DCHECK here - there should never be a situation where we
> don't actually have an active node id.

This may not be always true. When we reboot the device, I remember I see in LOG
the case active_input_node_id_ and active_input_node_id_ being zero cases. It
looks like we called GetNodes when we initialized CrasAudioHandler, and we can
receive ActiveInputNodeChanged and ActiveOutputNodeChanged events after the
callback of our GetNodes call and cras seems don't send us active input/output
nodes until these events triggers.

https://codereview.chromium.org/15927004/diff/4001/chromeos/audio/cras_audio_...
chromeos/audio/cras_audio_handler.cc:466: SetOutputMuteInternal(true);
On 2013/05/24 20:30:16, Rahul Chaturvedi wrote:
> What happens if output mute is locked? We still want to be able to mute when
> we're doing a switch.
> 

If output mute is locked, then the system is muted already by ApplyAudioPolicy.

[rkc, 2013-05-25 00:09:45]

lgtm

https://codereview.chromium.org/15927004/diff/4001/chromeos/audio/cras_audio_...
File chromeos/audio/cras_audio_handler.cc (right):

https://codereview.chromium.org/15927004/diff/4001/chromeos/audio/cras_audio_...
chromeos/audio/cras_audio_handler.cc:379: input_mute_on_ = kPrefMuteOff;
On 2013/05/24 21:23:49, jennyz wrote:
> On 2013/05/24 20:30:16, Rahul Chaturvedi wrote:
> > This else block is redundant. The GetMuteValue and GetVolumeGainValue will
> > return the default values if we don't have a saved value for the device
we're
> > checking.
> > 
> > We also should put a DCHECK here - there should never be a situation where
we
> > don't actually have an active node id.
> 
> This may not be always true. When we reboot the device, I remember I see in
LOG
> the case active_input_node_id_ and active_input_node_id_ being zero cases. It
> looks like we called GetNodes when we initialized CrasAudioHandler, and we can
> receive ActiveInputNodeChanged and ActiveOutputNodeChanged events after the
> callback of our GetNodes call and cras seems don't send us active input/output
> nodes until these events triggers.

Cool, the else block is then completely redundant. The Get calls will always
return at least the default values.

[commit-bot: I haz the power, 2013-05-25 00:17:37]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jennyz@chromium.org/15927004/13001

[commit-bot: I haz the power, 2013-05-25 14:41:13]

Commit queue rejected this change because the description was changed
between the time the change entered the commit queue and the time it
was ready to commit. You can safely check the commit box again.

[commit-bot: I haz the power, 2013-05-25 16:42:38]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jennyz@chromium.org/15927004/13001

[commit-bot: I haz the power, 2013-05-26 02:26:15]

Change committed as 202334