Detect AudioInputStream muting and propagate to MediaStreamAudioSource.

media/audio/audio_input_controller.cc

Index: media/audio/audio_input_controller.cc
diff --git a/media/audio/audio_input_controller.cc b/media/audio/audio_input_controller.cc
index 5c8997e0875b0853d02152b2c2d1ab6531f487ef..413bb3a30f9307aea843fdd56ad96afe861a54b6 100644
--- a/media/audio/audio_input_controller.cc
+++ b/media/audio/audio_input_controller.cc
@@ -26,6 +26,7 @@ namespace media {
 namespace {
 
 const int kMaxInputChannels = 3;
+constexpr int kCheckMutedStateIntervalSeconds = 1;
 
 #if defined(AUDIO_POWER_MONITORING)
 // Time in seconds between two successive measurements of audio power levels.
@@ -197,6 +198,7 @@ AudioInputController::AudioInputController(
 }
 
 AudioInputController::~AudioInputController() {
+  DCHECK(!check_muted_state_timer_);
   DCHECK(!audio_callback_);
   DCHECK(!stream_);
 }
@@ -353,6 +355,15 @@ void AudioInputController::DoCreateForStream(
   // Finally, keep the stream pointer around, update the state and notify.
   stream_ = stream_to_control;
   handler_->OnCreated(this);
+
+  // Check the current muted state and create a new repeating timer to keep that
+  // updated.
+  CheckMutedState();

[DaleCurtis, 2017/06/15 18:44:00]

Instead of using a repeating timer like this why not just check the muted state
during OnData() and post a task to the handler if it's muted? We already do that
for power level checks.

[ossu-chromium, 2017/06/20 12:25:15]

From looking at the implementations of IsMuted, they seem to be making calls
that would result in IPC (not Chrome IPC) and waiting for callbacks. I don't
want to put that kind of code in the audio input callback and risk introducing
latency issues. The call already there only happens once every 15 seconds, which
probably isn't often enough for proper feedback.

Once this chain of CLs has landed, I'd like to have a look at whether these
events could be listened for, instead of polling. If so, I'd be able to get rid
of this timer.

[DaleCurtis, 2017/06/20 17:08:09]

Which implementation are you worried about? I briefly checked the Windows/Mac
ones and they consist of the same type of calls we make elsewhere in the input
drivers.

[ossu-chromium, 2017/06/21 12:51:47]

I'm mostly concerned about the PulseAudio implementation, which does lock the
PulseAudio mainloop, issues an operation and waits for it to complete. I'd guess
that the Mac implementation results in at least one mach ipc call to coreaudiod.
Window seems to be using COM.

It's probably not that much of an issue once every 15 seconds, but I'd like to
avoid it within the callback if at all possible.

+  check_muted_state_timer_.emplace();
+  check_muted_state_timer_->Start(
+      FROM_HERE, base::TimeDelta::FromSeconds(kCheckMutedStateIntervalSeconds),
+      this, &AudioInputController::CheckMutedState);
+  DCHECK(check_muted_state_timer_->IsRunning());
 }
 
 void AudioInputController::DoRecord() {
@@ -382,6 +393,9 @@ void AudioInputController::DoClose() {
   if (!stream_)
     return;
 
+  // Stop and destroy the muted check timer.
+  check_muted_state_timer_.reset();
+
   // Allow calling unconditionally and bail if we don't have a stream to close.
   if (audio_callback_) {
     stream_->Stop();
@@ -652,6 +666,17 @@ bool AudioInputController::CheckAudioPower(const AudioBus* source,
 #endif
 }
 
+void AudioInputController::CheckMutedState() {
+  DCHECK(task_runner_->BelongsToCurrentThread());
+  DCHECK(stream_);
+  const bool new_state = stream_->IsMuted();
+  if (new_state != is_muted_) {
+    is_muted_ = new_state;
+    // We don't log OnMuted here, but leave that for AudioInputRendererHost.
+    handler_->OnMuted(this, is_muted_);
+  }
+}
+
 // static
 AudioInputController::StreamType AudioInputController::ParamsToStreamType(
     const AudioParameters& params) {