Make OS audio buffer size limits visible.

media/base/audio_latency.cc

Index: media/base/audio_latency.cc
diff --git a/media/base/audio_latency.cc b/media/base/audio_latency.cc
index 61b3724efa48cc36fc8ff7c3a545c95d7ba5bb56..908313842cde0d68302ef3cbee1a6517abf5105b 100644
--- a/media/base/audio_latency.cc
+++ b/media/base/audio_latency.cc
@@ -11,6 +11,11 @@
 #include "base/logging.h"
 #include "base/time/time.h"
 #include "build/build_config.h"
+#include "media/base/limits.h"
+
+#if defined(OS_MACOSX)
+#include "media/base/mac/audio_util_mac.h"
+#endif
 
 namespace media {
 
@@ -130,16 +135,32 @@ int AudioLatency::GetInteractiveBufferSize(int hardware_buffer_size) {
 int AudioLatency::GetExactBufferSize(base::TimeDelta duration,
                                      int sample_rate,
                                      int hardware_buffer_size) {
-  const double requested_buffer_size = duration.InSecondsF() * sample_rate;
-
   DCHECK_NE(0, hardware_buffer_size);
 
+// Windows and Android don't allow custom buffer sizes.
+#if defined(OS_WIN) || defined(OS_ANDROID)
+  return hardware_buffer_size;
+#else
+  const double requested_buffer_size = duration.InSecondsF() * sample_rate;
+  int minimum_buffer_size = hardware_buffer_size;
+
+// On OSX and CRAS the preferred buffer size is larger than the minimum,
+// however we allow values down to the minimum if requested explicitly.
+#if defined(OS_MACOSX)
+  minimum_buffer_size = audio_util_mac::GetMinAudioBufferSizeForSampleRate(
+      limits::kMinAudioBufferSize, sample_rate);
+#elif defined(USE_CRAS)
+  minimum_buffer_size = limits::kMinimumOutputBufferSize;

[o1ka, 2017/06/15 15:33:37]

Hmm, but AudioManagerCras::GetPreferredOutputStreamParameters() does not always
have 256 as a minimum, does it? It's defined by
GetMinimumOutputBufferSizePerBoard().

And are we sure we always want to have 256 as minimum? Will WebAudio users
really realize that 256 can result in a very poor experience on some boards on
ChromeOS?

[Raymond Toy, 2017/06/15 17:50:06]

I think that's ok.  Linux desktop can have really bad performance if we set the
size to 256, even on my z840. (In fact even today, one of our demos is
essentially broken on Linux because the pulseaudio callbacks are just too
irregular. I think.)

[o1ka, 2017/06/27 16:31:19]

The point was to return here exactly the buffer size which will be used on the
browser side, right? But we are always returning 256 here, instead of the real
minimum which is GetMinimumOutputBufferSizePerBoard().

The current approach is not consistent with what is done for Mac, or am I
missing something?

[Andrew MacPherson, 2017/06/27 17:03:40]

I may not have been clear when I asked about this earlier but the intention here
is to return per-board buffer sizes by default from
GetPreferredOutputStreamParameters(), but to allow requesting as low as 256 on
all boards if the user wants to. This does mean that
GetMinimumOutputBufferSizePerBoard() is a confusing name though, maybe it should
be updated to GetPreferredOutputBufferSizePerBoard()?

[o1ka, 2017/06/28 17:38:22]

I must be missing something: I don't see how
AudioManagerCras::GetPreferredOutputStreamParameters() will allow 256 on 'kevin'
board if requested?

[Andrew MacPherson, 2017/06/28 18:19:04]

You're completely right, my mistake. I've updated
AudioManagerCras::GetPreferredOutputStreamParameters() to use the
kMinAudioBufferSize rather than the board-based minimum, thanks for catching
this!

+#endif
+
   // Round the requested size to the nearest multiple of the hardware size
   const int buffer_size =
       std::round(std::max(requested_buffer_size, 1.0) / hardware_buffer_size) *
       hardware_buffer_size;
 
-  return std::max(buffer_size, hardware_buffer_size);
+  return std::min(static_cast<int>(limits::kMaxAudioBufferSize),
+                  std::max(buffer_size, minimum_buffer_size));
+#endif
 }
 
 }  // namespace media