Switch to STA mode for audio thread and WASAPI I/O streams.

media/audio/win/audio_manager_win.cc

Index: media/audio/win/audio_manager_win.cc
diff --git a/media/audio/win/audio_manager_win.cc b/media/audio/win/audio_manager_win.cc
index c09fb46284d6d8f4d1126816bf87d3dc6a9bee2e..9742fc9d66b780fd30a6e6e34a7218665250f2ef 100644
--- a/media/audio/win/audio_manager_win.cc
+++ b/media/audio/win/audio_manager_win.cc
@@ -129,23 +129,21 @@ static int NumberOfWaveOutBuffers() {
 }
 
 AudioManagerWin::AudioManagerWin(AudioLogFactory* audio_log_factory)
-    : AudioManagerBase(audio_log_factory),
-      // |CoreAudioUtil::IsSupported()| uses static variables to avoid doing
-      // multiple initializations.  This is however not thread safe.
-      // So, here we call it explicitly before we kick off the audio thread
-      // or do any other work.
-      enumeration_type_(CoreAudioUtil::IsSupported() ?

[tommi (sloooow) - chröme, 2015/04/20 18:23:38]

Is it safe to remove this call?  The comment explains why it's necessary to call
IsSupported here, so perhaps you've removed that requirement now?

[DaleCurtis, 2015/04/20 18:54:07]

I've moved video capture enumeration back to the audio thread which should be
the only caller into the audio manager this early.  I've also added a
kNoEnumeration state + DCHECK() to ensure no one is calling it.

That said, I just realized that this comment is talking about the IsSupported()
method itself and not the setup of AudioManager. Looking through the calls, the
problematic one looks like SystemMessageWindowWin() which happens slightly after
AudioManager initialization:

https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/sy...
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/br...

Or possibly even Ash initialization if the AudioManager thread is delayed
enough:

https://code.google.com/p/chromium/codesearch#chromium/src/ash/system/tray/sy...
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/...

I don't know if we should be initializing COM / changing the COM model for the
UI thread in these spots... Is there harm in that? Certainly it means we won't
have COM initialization until it's retried later on the audio thread... probably
this explains the mass crashes that we had previously here.

I think what we want to do is switch to a LazyInitializer in
CoreAudioUtil::IsSupported() and have it block until initialization completes on
the audio thread. All subsequent calls will use the cached value w/o blocking.
WDYT?

[DaleCurtis, 2015/04/20 23:06:10]

Hmm, things are worse than I thought here, TrayAudioDelegateWin() is actually
creating IMMDevice, ISimpleAudioVolume, and IAudioSessionManager objects on the
UI thread. These calls would need to trampoline to the audio thread if we want
to enforce calls to the audio thread.

Instead, I checked into the browser threads and it seems they're all initialized
with STA mode, so I think it's fine to let these calls go through. It does mean
keeping the AudioManagerWin constructor as is, so I've reverted all of those
changes and left only the STA changes for the WASAPI drivers.

-          kMMDeviceEnumeration : kWaveEnumeration) {
+    : AudioManagerBase(audio_log_factory), enumeration_type_(kNoEnumeration) {
   SetMaxOutputStreamsAllowed(kMaxOutputStreams);
 
   // WARNING: This is executed on the UI loop, do not add any code here which
   // loads libraries or attempts to call out into the OS.  Instead add such code
   // to the InitializeOnAudioThread() method below.
+  //
+  // WARNING: Do not make any calls to CoreAudioUtil within the constructor, it
+  // will attempt to perform COM initialization.
 
   // Task must be posted last to avoid races from handing out "this" to the
   // audio thread.
-  GetTaskRunner()->PostTask(FROM_HERE, base::Bind(
-      &AudioManagerWin::InitializeOnAudioThread, base::Unretained(this)));
+  GetTaskRunner()->PostTask(
+      FROM_HERE, base::Bind(&AudioManagerWin::InitializeOnAudioThread,
+                            base::Unretained(this)));
 }
 
 AudioManagerWin::~AudioManagerWin() {
@@ -166,6 +164,8 @@ bool AudioManagerWin::HasAudioInputDevices() {
 
 void AudioManagerWin::InitializeOnAudioThread() {
   DCHECK(GetTaskRunner()->BelongsToCurrentThread());
+  enumeration_type_ =
+      CoreAudioUtil::IsSupported() ? kMMDeviceEnumeration : kWaveEnumeration;
 
   if (core_audio_supported()) {
     // AudioDeviceListenerWin must be initialized on a COM thread and should
@@ -517,7 +517,7 @@ AudioInputStream* AudioManagerWin::CreatePCMWaveInAudioInputStream(
     const std::string& device_id) {
   std::string xp_device_id = device_id;
   if (device_id != AudioManagerBase::kDefaultDeviceId &&
-      enumeration_type_ == kMMDeviceEnumeration) {
+      enumeration_type() == kMMDeviceEnumeration) {
     xp_device_id = ConvertToWinXPInputDeviceId(device_id);
     if (xp_device_id.empty()) {
       DLOG(ERROR) << "Cannot find a waveIn device which matches the device ID "