Add UMA histograms for time spent getting WebRTC audio render data.

tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index 75f16fdd33e2dc9286685a4235553e439a553fba..fdab45abe94405768525ddd95b192b26f4dd92cc 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -65783,6 +65783,14 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
   <summary>Duration in milliseconds of WebRTC audio render session.</summary>
 </histogram>
 
+<histogram name="WebRTC.AudioRenderTimeMax" units="ms">
+  <owner>grunell@chromium.org</owner>
+  <summary>
+    The maximum time spent in WebRtcAudioRenderer::SourceCallback during a
+    session, i.e. between Start() and Stop() of WebRtcAudioRenderer.
+  </summary>
+</histogram>
+
 <histogram name="WebRTC.AudioRenderTimes" units="ms">
   <owner>henrika@chromium.org</owner>
   <summary>
@@ -65791,6 +65799,15 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
   </summary>
 </histogram>
 
+<histogram name="WebRTC.AudioRenderTimesAverage" units="ms">

[Ilya Sherman, 2016/08/22 21:17:47]

FWIW: If you do change the histogram to record data in microseconds, please
update the units as well.

[Henrik Grunell, 2016/08/23 10:42:04]

Done.

+  <owner>grunell@chromium.org</owner>
+  <summary>
+    Measures the average time spent in WebRtcAudioRenderer::SourceCallback over
+    periods of 1 second. WebRtcAudioRenderer::SourceCallback is called every 10
+    ms, so the average is over 100 function calls.

[Ilya Sherman, 2016/08/22 21:17:47]

Keep in mind that an average implemented as a mean is very susceptible to
influence by outliers.  It seems like what you really want is to have a per-user
view of the WebRTC.AudioRenderTimes histogram (though it's not clear to me why
that histogram is sampled...).  I think it might be worth exploring server-side
processing of the existing data, rather than adding additional client-side
histograms.

[Henrik Grunell, 2016/08/23 10:42:04]

Yes, and that's what we want. Ideally, we'd like to log every render call, but
that was pushed back when WebRTC.AudioRenderTimes was added quite a long time
ago. (Hence that metric measures every 10 call.) So second best is to log over a
period. We also have the max over a session to get that perspective too. And,
apart from the UMA data, we've also added tracing around this to analyze
individual users' audio rendering performance.
This overview is good to have, and for per user info the tracing will be very
helpful. Using WebRTC.AudioRenderTimes is not really helpful since it only
measures every 10 call. It might be time to deprecate it with the new one in
place, but I'd like to see them in parallel for a while first.

[Ilya Sherman, 2016/08/23 19:26:49]

Hmm, why was there pushback to recording every render call?  Histograms are
intended to be *very* efficient.

[Henrik Grunell, 2016/08/24 10:32:17]

I checked with the author and in the CL it was introduced in, and the reason
seems to have been to just err on the safe side. I've deprecated the current
histogram, and now log every call in the new one. Also renamed them to allow
adding the same data for other sources under a common naming. The logging is
done every 10 ms.

+  </summary>
+</histogram>
+
 <histogram name="WebRTC.BWE.InitialBandwidthEstimate" units="kbps">
   <owner>holmer@chromium.org</owner>
   <summary>The bandwidth estimate 2 seconds into a WebRTC call.</summary>