Support AudioContextOptions latencyHint as double.

media/base/audio_latency.cc

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "media/base/audio_latency.h"
 
 #include <stdint.h>
 
 #include <algorithm>
 
 #include "base/logging.h"
 #include "build/build_config.h"
+#include "media/base/audio_parameters.h"
 
 namespace media {
 
 namespace {
 #if !defined(OS_WIN)
 // Taken from "Bit Twiddling Hacks"
 // http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2
 uint32_t RoundUpToPowerOfTwo(uint32_t v) {
   v--;
   v |= v >> 1;
@@ skipping 96 matching lines @@
   // the jitter.
   const int kSmallBufferSize = 1024;
   const int kDefaultCallbackBufferSize = 2048;
   if (hardware_buffer_size <= kSmallBufferSize)
     return kDefaultCallbackBufferSize;
 #endif
 
   return hardware_buffer_size;
 }
 
+int AudioLatency::GetExactBufferSize(base::TimeDelta duration,
+                                     const AudioParameters& hardware_params) {
+  const int hardware_buffer_size = hardware_params.frames_per_buffer();
+  const double requested_buffer_size =
+      duration.InSecondsF() * hardware_params.sample_rate();
+
+  // Round up the requested size to the nearest multiple of the hardware size
+  const int buffer_size =
+      std::ceil(std::max(requested_buffer_size, 1.0) / hardware_buffer_size) *
+      hardware_buffer_size;

[o1ka, 2017/03/29 10:56:05]

It's actually not the nearest multiply (round), but nearest which does not
exceed the requested size. Is it what we want?

[Andrew MacPherson, 2017/03/30 08:07:18]

This was my intent but since both you and dalecurtis@ have mentioned "nearest
multiple" I've updated it to use a round() now, thanks!

+
+  const double twenty_ms_size = 2.0 * hardware_params.sample_rate() / 100;
+  const int max_buffer_size =
+      std::ceil(twenty_ms_size / hardware_buffer_size) * hardware_buffer_size;

[o1ka, 2017/03/29 10:56:05]

In fact, we are just limiting |duration| to 20 ms, right?
1) Is it really a limit we want to set for the users?
2) If so, we can just use min (duration, 0.02)

[DaleCurtis, 2017/03/29 22:42:41]

Hmm, this wasn't what I was proposing. I was proposing only doing what l.136
does. This code should just always return the nearest multiple (higher or lower)
to requested_buffer_size.

[Andrew MacPherson, 2017/03/30 08:07:18]

Sorry, my mistake here. I can remove this but I believe we'll still need to cap
the buffer size to some maximum. In Web Audio's AudioDestination.cpp there's a
FIFO used that can only hold up to 8064 frames and will crash otherwise. Also in
(for example) audio_manager_mac.cc there is kMaximumInputOutputBufferSize =
4096, I guess that higher values are just ignored and the maximum is used but
this would mean that the AudioContext.baseLatency would be incorrect if this
value is too high since the system will actually be using a lower value than the
one requested. Thoughts?

[DaleCurtis, 2017/03/30 18:53:46]

This should be removed from this code. We don't want to bake WebAudio
expectations into this piece. Instead WebAudio can clamp this as necessary in
it's own code.

Oversized buffers will be clamped during output, but you'll need to test what
happens when that occurs. There should be some sanity check on the values passed
in from WebAudio, i.e. perhaps the timedelta is clamped to < .5seconds or
something. Or even .2 if you want to max at high latency buffer size, but that's
a WebAudio decision and not something we should clamp in this function.

+
+  return std::max(std::min(buffer_size, max_buffer_size), hardware_buffer_size);
+}

[o1ka, 2017/03/29 10:56:05]

Dale - Is our intention to use multiplies of HW buffer size on all the
platforms, no more "power of 2" in GetHighLatencyBufferSize()?

[DaleCurtis, 2017/03/29 22:42:41]

Yes, I think that should be okay and likely will result in the same result since
platforms which don't care already specify a power of 2 buffer size.

[DaleCurtis, 2017/03/29 22:42:41]

Yes, I think that should be okay and likely will result in the same result since
platforms which don't care already specify a power of 2 buffer size.

[Andrew MacPherson, 2017/03/30 08:07:18]

Ok, I've updated GetHighLatencyBufferSize() to always round up to a multiple of
the HW buffer size, this also required updating
audio_renderer_mixer_manager_unittest.cc as it was expecting the "power of 2"
calculation. Let me know if I've misunderstood what was intended though.

+
 }  // namespace media