Implement two new policies to control muting the audio I/O.

chrome/browser/chromeos/audio/audio_mixer.h

Index: chrome/browser/chromeos/audio/audio_mixer.h
diff --git a/chrome/browser/chromeos/audio/audio_mixer.h b/chrome/browser/chromeos/audio/audio_mixer.h
index cb9dd67d951fbdb144392b99fdea37a3508220d0..6f9d51b444c6a48dbfeb098235b2d6660b52bd85 100644
--- a/chrome/browser/chromeos/audio/audio_mixer.h
+++ b/chrome/browser/chromeos/audio/audio_mixer.h
@@ -32,6 +32,24 @@ class AudioMixer {
   // Mutes or unmutes the device, possibly asynchronously.
   virtual void SetMuted(bool mute) = 0;

[Daniel Erat, 2012/08/27 17:38:35]

nit: document that callers must call IsMuteLocked() first and cannot call this
method if it returns true; ditto for SetCaptureMuted()

[pastarmovj, 2012/08/28 15:11:50]

Technically nothing prevents the caller to call SetMuted regardless of the
Locked state. However the mute state will not change but the observers will be
called to inform the interested parties that what the state after the operation
is. Added some more information about that to the comment though.

 
+  // Is the device's mute state currently locked?

[Mattias Nissler (ping if slow), 2012/08/28 12:24:24]

What does it mean to mute-luck the device? User cannot change the volume, or the
volume is forced to zero?

[pastarmovj, 2012/08/28 15:11:50]

To mute lock means that the audio inputs or outputs are locked for changing the
mute state and not the volume. A muted output will be muted regardless of the
volume level and unmuted devices will allow volume control but will not be
mutable (except of course through setting the volume to 0). Right now there is
no real use case for locking the mute  state in unmuted so I might as well limit
the API as suggested here to only allow locking in the muted state.

+  virtual bool IsMuteLocked() = 0;
+
+  // Locks the mute state of the device.
+  virtual void SetMuteLocked(bool locked) = 0;

[Daniel Erat, 2012/08/27 17:38:35]

Would we ever want to lock the device in an unmuted or capture-unmuted state? 
If not, it'd probably be a good idea to add a DCHECK() in the implementations of
this and SetCaptureMuteLocked() to ensure that the "muted" variables are true
(and to document that here).

Actually, thinking about this more: Does all access to the AudioMixer classes go
through AudioHandler?  I believe so.  If so, why not just enforce the policy in
AudioHandler instead of needing to enforce it in all of the AudioMixer
implementations?

[pastarmovj, 2012/08/28 15:11:50]

Actually it is needed especially in the AudioMixerCras implementation as we have
support to lock the server's mute state which will guarantee that no other
process will be able to unmute the device. The fact that I have implemented the
locking on the client side as well is more to provide consistency with the soft
locking in Alsa.

+
+  // Is the capture device currently muted?
+  virtual bool IsCaptureMuted() = 0;
+
+  // Mutes or unmutes the capture device, possible asynchronously.
+  virtual void SetCaptureMuted(bool mute) = 0;
+
+  // Is the capture device's mute state currently locked?
+  virtual bool IsCaptureMuteLocked() = 0;
+
+  // Locks the capture mute state of the device.
+  virtual void SetCaptureMuteLocked(bool locked) = 0;
+
  private:
   DISALLOW_COPY_AND_ASSIGN(AudioMixer);
 };