Change the way we are sending audio data to driver when using WaveOut API.

media/audio/audio_util.cc

 // Copyright (c) 2011 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.
 
 // Software adjust volume of samples, allows each audio stream its own
 // volume without impacting master volume for chrome and other applications.
 
 // Implemented as templates to allow 8, 16 and 32 bit implementations.
 // 8 bit is unsigned and biased by 128.
 
@@ skipping 275 matching lines @@
   // The sizes here were determined by experimentation and are roughly
   // the lowest value (for low latency) that still allowed glitch-free
   // audio under high loads.
   //
   // For Mac OS X and Windows the chromium audio backend uses a low-latency
   // Core Audio API, so a low buffer size is possible. For Linux, further
   // tuning may be needed.
 #if defined(OS_MACOSX)
   return 128;
 #elif defined(OS_WIN)
+  if (base::win::GetVersion() <= base::win::VERSION_XP) {

[henrika (OOO until Aug 14), 2011/11/29 12:20:42]

This will most likely not work!

It is correct that the VERSION_XP check is needed. I had missed that in my last
patch.

BUT, the buffer size must be modified manually and tweaked by Raymond. It used
to be 2048 for Windows but since then the WebKit part in WebAudio has changed.

Again, you must ensure that Raymond helps you determine the best value here. It
will depend on the new timing.

[Raymond Toy (Google), 2011/11/29 18:13:57]

This will mostly likely need to be set to 2048 again instead of 480.  I do not
have an XP machine to test with, so I will have to fake it somehow to test that
the waveout method still works.

+    // Fall back to Windows Wave implementation on Windows XP or lower
+    // and assume 48kHz as default sample rate.
+    return 480;

[Raymond Toy (Google), 2011/11/29 18:45:29]

I tested this on my Windows 7 machine by adjusting the checks to pretend this is
a XP machine.  Webaudio is horrible with this, so please change the 480 back to
2048.

[enal, 2011/11/29 18:57:44]

2048 does not help with either new or old implementation on both Win7 and XP.
Increasing number of buffers to 3 does not help either.

[Raymond Toy (Google), 2011/11/29 20:01:29]

This seems not right.  How did you test this?  2048 sounds fine for me on my
Win7 machine with the XP tests changed to pretend I'm on an XP machine.

2048 was the value before Henrik added WASAPI, and that sounded fine on my
machine.  

Do you have an example that sounds bad?  I just ran the drumkit demo (and a few
random other webaudio demos).

[enal, 2011/11/29 21:02:45]

I figured out what my problem was when testing on Win7. I forced audio manager
to use wave out, but did not modify the code to set buffer size to 2k, so it
used one for WASAPI because it is running on Win7. When I forced buffer size to
2k on Win7 everything became fine.

Still broken on my XP, both old and new code, maybe because it has only 512Mb
RAM. I ordered extra 512Mb, for testing in the future.

+  }
   // This call must be done on a COM thread configured as MTA.
   // TODO(tommi): http://code.google.com/p/chromium/issues/detail?id=103835.
   int mixing_sample_rate =
       static_cast<int>(WASAPIAudioOutputStream::HardwareSampleRate(eConsole));
   if (mixing_sample_rate == 48000)
     return 480;
   else if (mixing_sample_rate == 44100)
     return 448;
   else
     return 960;
@@ skipping 46 matching lines @@
   char* ptr = static_cast<char*>(shared_memory->memory()) + shared_memory_size;
   DCHECK_EQ(0u, reinterpret_cast<size_t>(ptr) & 3);
 
   // Actual data size stored at the end of the buffer.
   uint32 actual_data_size =
       base::subtle::Acquire_Load(reinterpret_cast<volatile Atomic32*>(ptr));
   return actual_data_size == kUnknownDataSize;
 }
 
 }  // namespace media