Lowering the audio peak treshold a bit after Android flakes.

We got these samples off an Android device just now:

"..,15934,15934,15934,15934,15934,15934,3983,3983,3983,83..
 ..207,31513,31513,31513,31513,31513,31513,31513,31513,7878,7878,7878,
 ..21676,21676,21676,21676,21676,21676,5419,5419,5419,5419,5419,1354,..
 ..1354,1354,1354,1354,1354,338,338,338,713,713,713,713"

There are three peaks in this signal but the 15934 and 21676 is too low
to make it over the peak treshold.

The problem doesn't seem to be that we sample to little since we get
several high values in a row, nor does it seem the sampling is too
slow as the affected test took five seconds to execute, which seems
about right. I wonder if our stats API is too sluggish on Android so
it doesn't record the peaks of the audio signal. Either that, or the
audio signal is mangled on Android so it in effect is amplitude
reduced.

The signal is still pretty clear so I'll just adjust the threshold a
bit. We're mostly lookin for completely broken audio here, and this
just looks slightly mangled.

R=perkj@chromium.org
BUG=362432

Review URL: https://codereview.chromium.org/231983007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@263237 0039d316-1c4b-4281-b951-d872f2087c98

2 files changed, 6 insertions, 12 deletions

diff --git a/content/browser/media/webrtc_browsertest.cc b/content/browser/media/webrtc_browsertest.cc
index 283622b..9f1d522 100644
--- a/content/browser/media/webrtc_browsertest.cc
+++ b/content/browser/media/webrtc_browsertest.cc
@@ -308,17 +308,8 @@ IN_PROC_BROWSER_TEST_P(WebRtcBrowserTest,
   MakeTypicalPeerConnectionCall("callAndEnsureAudioIsPlaying();");
 }
 
-#if defined(OS_ANDROID)
-// Flaky on Android: http://crbug.com/362432
-#define MAYBE_EstablishAudioVideoCallAndVerifyMutingWorks \
-    FLAKY_EstablishAudioVideoCallAndVerifyMutingWorks
-#else
-#define MAYBE_EstablishAudioVideoCallAndVerifyMutingWorks \
-    EstablishAudioVideoCallAndVerifyMutingWorks
-#endif
-
 IN_PROC_BROWSER_TEST_P(WebRtcBrowserTest,
-                       MAYBE_EstablishAudioVideoCallAndVerifyMutingWorks) {
+                       EstablishAudioVideoCallAndVerifyMutingWorks) {
   if (!media::AudioManager::Get()->HasAudioOutputDevices()) {
     // Bots with no output devices will force the audio code into a different
     // path where it doesn't manage to set either the low or high latency path.
diff --git a/content/test/data/media/webrtc_test_audio.js b/content/test/data/media/webrtc_test_audio.js
index 52c7d38..76ca1b3 100644
--- a/content/test/data/media/webrtc_test_audio.js
+++ b/content/test/data/media/webrtc_test_audio.js
@@ -29,10 +29,13 @@ function gatherAudioLevelSamples(peerConnection, numSamples, frequency,
 // audio device in media/video/capture/fake_video_capture_device.cc. Fails the
 // test if we can't see a signal. The samples should have been gathered over at
 // least two seconds since we expect to see at least three "peaks" in there
-// (we should see either 3 or 4 depending on how things line up).
+// (we should see either 3 or 4 depending on how things line up). We are quite
+// generous in what we consider to be a peak since Android devices in particular
+// seem to be flake-prone (they often don't reach anywhere near the max level
+// for some reason).
 function verifyAudioIsPlaying(samples) {
   var numPeaks = 0;
-  var threshold = MAX_AUDIO_OUTPUT_ENERGY * 0.7;
+  var threshold = MAX_AUDIO_OUTPUT_ENERGY * 0.6;
   var currentlyOverThreshold = false;
 
   // Detect when we have been been over the threshold and is going back again