Return fixed hardware buffer size for odd sample rates.

media/audio/audio_util.cc

Index: media/audio/audio_util.cc
diff --git a/media/audio/audio_util.cc b/media/audio/audio_util.cc
index 2b4fd1742e1c090e8bc0f57a94f6399d4705a42f..086366354b7d1b45582f19c3b504a7e011e30663 100644
--- a/media/audio/audio_util.cc
+++ b/media/audio/audio_util.cc
@@ -32,6 +32,7 @@
 #include "media/audio/audio_manager_base.h"
 #include "media/audio/win/audio_low_latency_input_win.h"
 #include "media/audio/win/audio_low_latency_output_win.h"
+#include "media/base/limits.h"
 #include "media/base/media_switches.h"
 #endif
 
@@ -305,10 +306,13 @@ size_t GetAudioHardwareBufferSize() {
 #if defined(OS_MACOSX)
   return 128;
 #elif defined(OS_WIN)
+  // Buffer size to use when a proper size can't be determined from the system.
+  static const int kFallbackBufferSize = 2048;
+
   if (!IsWASAPISupported()) {
     // Fall back to Windows Wave implementation on Windows XP or lower
     // and assume 48kHz as default sample rate.
-    return 2048;
+    return kFallbackBufferSize;
   }
 
   // TODO(crogers): tune this size to best possible WebAudio performance.
@@ -324,6 +328,11 @@ size_t GetAudioHardwareBufferSize() {
   int mixing_sample_rate =
       WASAPIAudioOutputStream::HardwareSampleRate(eConsole);
 
+  // Windows will return a sample rate of 0 when no audio output is available,
+  // but we should never return a buffer size of zero.
+  if (mixing_sample_rate == 0)
+    return kFallbackBufferSize;
+
   // Use different buffer sizes depening on the sample rate . The existing
   // WASAPI implementation is tuned to provide the most stable callback
   // sequence using these combinations.
@@ -335,8 +344,11 @@ size_t GetAudioHardwareBufferSize() {
     // Use buffer size of 10ms.
     return (80 * (mixing_sample_rate / 8000));
 
+  // Ensure we always return a buffer size which is somewhat appropriate.
   LOG(ERROR) << "Unknown sample rate " << mixing_sample_rate << " detected.";
-  return (mixing_sample_rate / 100);
+  if (mixing_sample_rate > limits::kMinSampleRate)
+    return (mixing_sample_rate / 100);
+  return kFallbackBufferSize;

[Ami GONE FROM CHROMIUM, 2012/09/25 18:25:46]

any reason you're going to 2048 here from the 960 it was before the previous
change?

[DaleCurtis, 2012/09/25 18:39:30]

Most cases are now handled by the mixing_sample_rate / 100, in cases where we've
got a crazy sample rate < 8kHz, I think a larger buffer size is more prudent.

Although it doesn't really matter since the fallback code is going to say hell
no when it tries to verify the configuration and choose a high latency
appropriate buffer size via another algorithm.

 #else
   return 2048;

[Ami GONE FROM CHROMIUM, 2012/09/25 18:25:46]

constify

[DaleCurtis, 2012/09/25 18:39:30]

I intentionally skipped this because it's not in the #OS_WIN section but rather
the default buffer size for Linux, i.e. not a fallback buffer size :)

 #endif