UMA histogram WebRTC.AecDelayBasedQuality updated

content/renderer/media/media_stream_audio_processor.cc

Index: content/renderer/media/media_stream_audio_processor.cc
diff --git a/content/renderer/media/media_stream_audio_processor.cc b/content/renderer/media/media_stream_audio_processor.cc
index 750e682bd06f88de7034a462343e594b8fa2550a..bee0638ac79332d3677a848c8ecbbf7711b0db7b 100644
--- a/content/renderer/media/media_stream_audio_processor.cc
+++ b/content/renderer/media/media_stream_audio_processor.cc
@@ -419,8 +419,6 @@ void MediaStreamAudioProcessor::GetStats(AudioProcessorStats* stats) {
   stats->typing_noise_detected =
       (base::subtle::Acquire_Load(&typing_detected_) != false);
   GetAecStats(audio_processing_.get(), stats);
-  if (echo_information_)
-    echo_information_.get()->UpdateAecDelayStats(stats->echo_delay_median_ms);
 }
 
 void MediaStreamAudioProcessor::InitializeAudioProcessingModule(
@@ -679,6 +677,10 @@ int MediaStreamAudioProcessor::ProcessData(const float* const* process_ptrs,
     base::subtle::Release_Store(&typing_detected_, detected);
   }
 
+  if (echo_information_) {
+    echo_information_.get()->UpdateAecDelayStats(ap);

[perkj_chrome, 2015/02/09 07:53:13]

Is it safe to access echo_information_ on this thread? Looks like its created on
one thread and used on another. 

[bjornv, 2015/02/09 11:11:16]

Then, isn't it unsafe to use audio_processing_ at all, since it is created on
main_thread, but used on capture_thread just like echo_information_

[perkj_chrome, 2015/02/09 11:48:30]

true, and that seems to be the only place it is touched. 

+  }
+
   // Return 0 if the volume hasn't been changed, and otherwise the new volume.
   return (agc->stream_analog_level() == volume) ?
       0 : agc->stream_analog_level();