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

content/renderer/media/media_stream_audio_processor_options.cc

Index: content/renderer/media/media_stream_audio_processor_options.cc
diff --git a/content/renderer/media/media_stream_audio_processor_options.cc b/content/renderer/media/media_stream_audio_processor_options.cc
index c447404e868f4b9c53eab84dc2737bf795e9295a..0cf7ad241ba3ffbfcc72ab724ddf36f5960adbff 100644
--- a/content/renderer/media/media_stream_audio_processor_options.cc
+++ b/content/renderer/media/media_stream_audio_processor_options.cc
@@ -178,4 +178,43 @@ void EnableAutomaticGainControl(AudioProcessing* audio_processing) {
   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