Clean up audio-related utility functions to compute buffer sizes

content/renderer/media/audio_hardware.cc

Index: content/renderer/media/audio_hardware.cc
diff --git a/content/renderer/media/audio_hardware.cc b/content/renderer/media/audio_hardware.cc
index 183ebecd529510bea3e2d132f02ebe447f44ea10..1f49fdb991103682a94fe09a49f9693b51dff643 100644
--- a/content/renderer/media/audio_hardware.cc
+++ b/content/renderer/media/audio_hardware.cc
@@ -48,6 +48,31 @@ size_t GetOutputBufferSize() {
   return output_buffer_size;
 }
 
+size_t GetHighLatencyOutputBufferSize(int sample_rate) {

[vrk (LEFT CHROMIUM), 2012/02/23 01:06:42]

In CL 9416085, I deleted another version of this function:

 static size_t GetBufferSizeForSampleRate(int sample_rate) {
   // kNominalBufferSize has been tested on Windows, Mac OS X, and Linux
   // using the low-latency audio codepath (SyncSocket implementation
   // with the AUDIO_PCM_LINEAR flag.
   const size_t kNominalBufferSize = 2048;	
 	
   if (sample_rate <= 48000)	
     return kNominalBufferSize;	
   else if (sample_rate <= 96000)	
     return kNominalBufferSize * 2;	
    return kNominalBufferSize * 4;	
  }

This function ended up returning values too small for AudioRendererAlgorithmBase
to handle, which in turn resulted in crbug.com/108239

crogers: How did you get the numbers above? If the AUDIO_PCM_LINEAR flag is
turned on, will we get better performance from the above computation rather than
the computation below?

[Chris Rogers, 2012/02/23 19:00:21]

The base value of 2048 was chosen as a value not too big and not too small.  The
Web Audio API has used this value for a long time using the wavOut and ALSA
back-ends and has generally been high enough to work well.  So I thought it
should be safe here as well.

But other than that, no special significance should be attached to it.

On 2012/02/23 01:06:42, Victoria Kirst wrote:

+  // The minimum number of samples in a hardware packet.
+  // This value is selected so that we can handle down to 5khz sample rate.
+  static const size_t kMinSamplesPerHardwarePacket = 1024;
+
+  // The maximum number of samples in a hardware packet.
+  // This value is selected so that we can handle up to 192khz sample rate.
+  static const size_t kMaxSamplesPerHardwarePacket = 64 * 1024;
+
+  // This constant governs the hardware audio buffer size, this value should be
+  // chosen carefully.
+  // This value is selected so that we have 8192 samples for 48khz streams.
+  static const size_t kMillisecondsPerHardwarePacket = 170;
+
+  // Select the number of samples that can provide at least
+  // |kMillisecondsPerHardwarePacket| worth of audio data.
+  size_t samples = kMinSamplesPerHardwarePacket;
+  while (samples <= kMaxSamplesPerHardwarePacket &&
+         samples * base::Time::kMillisecondsPerSecond <
+         sample_rate * kMillisecondsPerHardwarePacket) {
+    samples *= 2;

[Chris Rogers, 2012/02/23 19:00:21]

I think this should be fine for now in order to fix the playback-rate bug.  But
it *does* significantly increase the latency.  So if the long-term goal is to
improve <audio> latency, then in the longer term we should try to fix the
playback-rate bug another way and find smaller/better values here.

[vrk (LEFT CHROMIUM), 2012/02/23 22:33:18]

Thanks Chris, that's good to know! Here I have a proper fix for the
playback-rate bug: https://chromiumcodereview.appspot.com/9395057/
which will land after I land this CL (9442005). I just modified CL9395057 so
that it rewrites this function to use the faster kNominalBufferSize logic above.

So for M18 we'll have to live with the higher latency buffer sizes, but in M19
the bug will be fixed property and the lower latency buffer size computation
(for  GetHighLatencyOutputBufferSize()) will be restored.

+  }
+  return samples;
+}
+
 uint32 GetInputChannelCount() {
   DCHECK(RenderThreadImpl::current() != NULL);