Support for AudioContextOptions latencyHint.

third_party/WebKit/Source/platform/audio/AudioDestination.cpp

Index: third_party/WebKit/Source/platform/audio/AudioDestination.cpp
diff --git a/third_party/WebKit/Source/platform/audio/AudioDestination.cpp b/third_party/WebKit/Source/platform/audio/AudioDestination.cpp
index 39903c682010aa23536b1e7061ebce9d5a012e0b..021a774700aed47109adccb31d9d2a007d817233 100644
--- a/third_party/WebKit/Source/platform/audio/AudioDestination.cpp
+++ b/third_party/WebKit/Source/platform/audio/AudioDestination.cpp
@@ -34,6 +34,7 @@
 #include "platform/audio/AudioUtilities.h"
 #include "platform/weborigin/SecurityOrigin.h"
 #include "public/platform/Platform.h"
+#include "public/platform/WebAudioLatencyHint.h"
 #include "public/platform/WebSecurityOrigin.h"
 #include "wtf/PtrUtil.h"
 #include <memory>
@@ -49,18 +50,18 @@ std::unique_ptr<AudioDestination> AudioDestination::create(
     const String& inputDeviceId,
     unsigned numberOfInputChannels,
     unsigned numberOfOutputChannels,
-    float sampleRate,
+    const WebAudioLatencyHint& latencyHint,
     PassRefPtr<SecurityOrigin> securityOrigin) {
   return wrapUnique(new AudioDestination(
       callback, inputDeviceId, numberOfInputChannels, numberOfOutputChannels,
-      sampleRate, std::move(securityOrigin)));
+      latencyHint, std::move(securityOrigin)));
 }
 
 AudioDestination::AudioDestination(AudioIOCallback& callback,
                                    const String& inputDeviceId,
                                    unsigned numberOfInputChannels,
                                    unsigned numberOfOutputChannels,
-                                   float sampleRate,
+                                   const WebAudioLatencyHint& latencyHint,

[o1ka, 2016/11/30 11:46:26]

WebAudioLatencyHint class really makes the code look heavier: const refs are not
needed if we use enum directly.

[Raymond Toy, 2016/11/30 21:50:27]

I think this is the right approach because the latencyHint will eventually
include a double in addition to the enum.  I've proposed that the IDL should
include that, and to treat any float value as the same as interactive.  At least
for the first cut.

                                    PassRefPtr<SecurityOrigin> securityOrigin)
     : m_callback(callback),
       m_numberOfOutputChannels(numberOfOutputChannels),
@@ -69,7 +70,6 @@ AudioDestination::AudioDestination(AudioIOCallback& callback,
       m_renderBus(AudioBus::create(numberOfOutputChannels,
                                    AudioUtilities::kRenderQuantumFrames,
                                    false)),
-      m_sampleRate(sampleRate),
       m_isPlaying(false) {
   // Histogram for audioHardwareBufferSize
   DEFINE_STATIC_LOCAL(SparseHistogram, hardwareBufferSizeHistogram,
@@ -80,41 +80,20 @@ AudioDestination::AudioDestination(AudioIOCallback& callback,
   DEFINE_STATIC_LOCAL(SparseHistogram, callbackBufferSizeHistogram,
                       ("WebAudio.AudioDestination.CallbackBufferSize"));
 
-  // Use the optimal buffer size recommended by the audio backend.
-  size_t recommendedHardwareBufferSize =
-      Platform::current()->audioHardwareBufferSize();
-  m_callbackBufferSize = recommendedHardwareBufferSize;
-
-#if OS(ANDROID)
-  // The optimum low-latency hardware buffer size is usually too small on
-  // Android for WebAudio to render without glitching. So, if it is small, use
-  // a larger size. If it was already large, use the requested size.
-  //
-  // Since WebAudio renders in 128-frame blocks, the small buffer sizes (144
-  // for a Galaxy Nexus), cause significant processing jitter. Sometimes
-  // multiple blocks will processed, but other times will not be since the FIFO
-  // can satisfy the request. By using a larger callbackBufferSize, we smooth
-  // out the jitter.
-  const size_t kSmallBufferSize = 1024;
-  const size_t kDefaultCallbackBufferSize = 2048;
-
-  if (m_callbackBufferSize <= kSmallBufferSize)
-    m_callbackBufferSize = kDefaultCallbackBufferSize;
-#endif
+  m_audioDevice = wrapUnique(Platform::current()->createAudioDevice(
+      numberOfInputChannels, numberOfOutputChannels, latencyHint, this,
+      inputDeviceId, std::move(securityOrigin)));
+  DCHECK(m_audioDevice);
 
+  m_callbackBufferSize = m_audioDevice->framesPerBuffer();
   // Quick exit if the requested size is too large.
   DCHECK_LE(m_callbackBufferSize + AudioUtilities::kRenderQuantumFrames,
             fifoSize);
   if (m_callbackBufferSize + AudioUtilities::kRenderQuantumFrames > fifoSize)
     return;
 
-  m_audioDevice = wrapUnique(Platform::current()->createAudioDevice(
-      m_callbackBufferSize, numberOfInputChannels, numberOfOutputChannels,
-      sampleRate, this, inputDeviceId, std::move(securityOrigin)));
-  ASSERT(m_audioDevice);
-
   // Record the sizes if we successfully created an output device.
-  hardwareBufferSizeHistogram.sample(recommendedHardwareBufferSize);
+  hardwareBufferSizeHistogram.sample(m_callbackBufferSize);

[o1ka, 2016/11/30 11:46:26]

rtoy@/hongchan@ what is your recommendation for these histograms?
What exactly does WebAudio register in them?
They may need to be moved to WebAudioDeviceImpl.

[Raymond Toy, 2016/11/30 20:37:29]

We do definitely want to keep these around.  They're pretty important to
understand what kind of Android devices are out there;  there seems to be much
less variation in desktop values.

[Andrew MacPherson, 2016/12/01 12:11:56]

Should I move these to the WebAudioDeviceImpl then?

[Andrew MacPherson, 2016/12/02 09:42:55]

Maybe for now the easiest thing is to just use the
Platform::audioHardwareBufferSize() here as before and this can be updated in a
subsequent CL where audioHardwareBufferSize() is removed entirely? I've updated
the code to do this now.

[Raymond Toy, 2016/12/02 16:57:45]

If this preserves the current values, then I'm fine with it. I just would prefer
not to see a (short) glitch in the stats.

   callbackBufferSizeHistogram.sample(m_callbackBufferSize);
 
   // Create a FIFO to handle the possibility of the callback size