Fix flaky AudioStreamHandler initialization.

AudioStreamHandler was calling into the AudioManager on the wrong
thread.  On OSX this will lead to undefined behavior since the
CoreAudio API is not thread safe.

Sadly due to antique unit tests, we don't have the proper DCHECKs
in place to catch bad behavior automatically.  I've filed the bug
below to track this effort.

In this case we can simply use a fixed buffer size since ASH is
using MakeAudioOutputStreamProxy() which will take care of any
necessary rebuffering and resampling.

BUG=325373
TEST=none
R=scherkus@chromium.org

Review URL: https://codereview.chromium.org/102693003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@238484 0039d316-1c4b-4281-b951-d872f2087c98

media/audio/sounds/audio_stream_handler.cc

@@ -19,6 +19,9 @@ namespace {
 // Volume percent.
 const double kOutputVolumePercent = 0.8;
 
+// The number of frames each OnMoreData() call will request.
+const int kDefaultFrameCount = 1024;
+
 AudioStreamHandler::TestObserver* g_observer_for_testing = NULL;
 AudioOutputStream::AudioSourceCallback* g_audio_source_for_testing = NULL;
 
@@ -124,12 +127,11 @@ AudioStreamHandler::AudioStreamHandler(const base::StringPiece& wav_data)
     LOG(ERROR) << "Can't get access to audio manager.";
     return;
   }
-  AudioParameters params(
-      AudioParameters::AUDIO_PCM_LOW_LATENCY,
-      GuessChannelLayout(wav_audio_.num_channels()),
-      wav_audio_.sample_rate(),
-      wav_audio_.bits_per_sample(),
-      manager->GetDefaultOutputStreamParameters().frames_per_buffer());
+  AudioParameters params(AudioParameters::AUDIO_PCM_LOW_LATENCY,
+                         GuessChannelLayout(wav_audio_.num_channels()),
+                         wav_audio_.sample_rate(),
+                         wav_audio_.bits_per_sample(),
+                         kDefaultFrameCount);
   if (!params.IsValid()) {
     LOG(ERROR) << "Audio params are invalid.";
     return;