Add a new UMA metric in APM to track incoming capture-side audio level

webrtc/modules/audio_processing/audio_processing_impl.cc

Index: webrtc/modules/audio_processing/audio_processing_impl.cc
diff --git a/webrtc/modules/audio_processing/audio_processing_impl.cc b/webrtc/modules/audio_processing/audio_processing_impl.cc
index 39c79cdf5c562e06f1916dd16696360791389d4e..0ab4db16aad4bd5292bb45dee6b58bd034de330e 100644
--- a/webrtc/modules/audio_processing/audio_processing_impl.cc
+++ b/webrtc/modules/audio_processing/audio_processing_impl.cc
@@ -1095,6 +1095,18 @@ int AudioProcessingImpl::ProcessCaptureStreamLocked() {
 
   AudioBuffer* capture_buffer = capture_.capture_audio.get();  // For brevity.
 
+  rms_.Process(rtc::ArrayView<const int16_t>(
+      capture_buffer->channels_const()[0],
+      capture_nonlocked_.capture_processing_format.num_frames()));
+  if (++rms_interval_counter_ >= 1000) {
+    rms_interval_counter_ = 0;
+    RMSLevel::Levels levels = rms_.AverageAndPeak();
+    RTC_HISTOGRAM_COUNTS("WebRTC.Audio.ApmCaptureInputLevelAverage",
+                         levels.average, 1, RMSLevel::kMinLevelDb, 100);

[peah-webrtc, 2016/11/29 09:02:27]

Why having a minimum value of 0? For a signal of maximum level the maximum value
is 0 dBFS.

[hlundin-webrtc, 2016/11/29 11:02:39]

The value we get is between 0 and 127, which corresponds to 0 to -127 dBFS. And
since UMA histograms always create a zero-bucket anyway, the range [1, 127]
makes sense imo.

+    RTC_HISTOGRAM_COUNTS("WebRTC.Audio.ApmCaptureInputLevelPeak", levels.peak,
+                         1, RMSLevel::kMinLevelDb, 100);

[peah-webrtc, 2016/11/29 09:02:27]

Why having a minimum value of 0? For a signal of maximum level the maximum value
is 0 dBFS.

[hlundin-webrtc, 2016/11/29 11:02:39]

See above.

+  }
+
   if (constants_.use_experimental_agc &&
       public_submodules_->gain_control->is_enabled()) {
     private_submodules_->agc_manager->AnalyzePreProcess(