Implements the GetSignalLevel and GetStats interface for the local audio track.

content/renderer/media/media_stream_audio_processor_options.cc

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/renderer/media/media_stream_audio_processor_options.h"
 
 #include "base/files/file_path.h"
 #include "base/logging.h"
 #include "base/path_service.h"
 #include "base/strings/utf_string_conversions.h"
@@ skipping 160 matching lines @@
 #if defined(OS_ANDROID) || defined(OS_IOS)
   const webrtc::GainControl::Mode mode = webrtc::GainControl::kFixedDigital;
 #else
   const webrtc::GainControl::Mode mode = webrtc::GainControl::kAdaptiveAnalog;
 #endif
   int err = audio_processing->gain_control()->set_mode(mode);
   err |= audio_processing->gain_control()->Enable(true);
   CHECK_EQ(err, 0);
 }
 
+void GetAecStats(AudioProcessing* audio_processing,

[ajm, 2014/03/04 02:23:12]

How often is this method polled? Calling GetMetrics() averages over the window
since the last call to it and resets the metrics.

You don't want to poll this often and report at a much lower frequency. Ideally
the polling and reporting would have the same frequency. (Though unfortunately
that's not the way it works in libjingle at the moment. It's polled at a 1
second interval and reported at a 10 second. Would be great to improve :)

[no longer working on chromium, 2014/03/04 15:48:59]

Definitely.

The method is triggered by StatsCollector::ExtractVoiceInfo, so it is the same
frequency as StatsCollector::GetStats().

I measured the frequency using ML, it looks like libjingle is polling every
200ms instead of every 1 second. I am not sure if something has been changed or
it is the way for a long time.
There might be ways to optimize this GetStats() call in libjingle, but there is
nothing we can do here in chrome.

+                 webrtc::AudioProcessorInterface::AudioProcessorStats* stats) {
+  // These values can take on valid negative values, so use the lowest possible
+  // level as default rather than -1.
+  stats->echo_return_loss = -100;

[tommi (sloooow) - chröme, 2014/03/03 15:25:18]

Where is it documented that these are the lowest possible values?
Would it make sense to have constants defined somewhere for them?

[ajm, 2014/03/04 02:23:12]

I had a look and unfortunately it's not documented anywhere, but I can confirm
this is indeed the case.

[no longer working on chromium, 2014/03/04 15:48:59]

Thanks.

+  stats->echo_return_loss_enhancement = -100;
+
+  // These values can also be negative, but in practice -1 is only used to
+  // signal insufficient data, since the resolution is limited to multiples
+  // of 4ms.
+  stats->echo_delay_median_ms = -1;
+  stats->echo_delay_std_ms = -1;
+
+  // TODO(ajm): Re-enable this metric once we have a reliable implementation.
+  stats->aec_quality_min = -1.0f;
+
+  if (!audio_processing->echo_cancellation()->are_metrics_enabled() ||
+      !audio_processing->echo_cancellation()->is_delay_logging_enabled() ||
+      !audio_processing->echo_cancellation()->is_enabled()) {
+    return;
+  }
+
+  // TODO(ajm): we may want to use VoECallReport::GetEchoMetricsSummary
+  // here, but it appears to be unsuitable currently. Revisit after this is
+  // investigated: http://b/issue?id=5666755
+  webrtc::EchoCancellation::Metrics echo_metrics;
+  if (!audio_processing->echo_cancellation()->GetMetrics(&echo_metrics)) {
+    stats->echo_return_loss = echo_metrics.echo_return_loss.instant;
+    stats->echo_return_loss_enhancement =
+        echo_metrics.echo_return_loss_enhancement.instant;
+  }
+
+  int median = 0, std = 0;
+  if (!audio_processing->echo_cancellation()->GetDelayMetrics(&median, &std)) {
+    stats->echo_delay_median_ms = median;
+    stats->echo_delay_std_ms = std;
+  }
+}
+
 }  // namespace content