Lazily initialize MessageLoop for faster thread startup

media/audio/audio_manager_base.cc

Index: media/audio/audio_manager_base.cc
diff --git a/media/audio/audio_manager_base.cc b/media/audio/audio_manager_base.cc
index edaabf4c22771e71ef38a1fba14f4969e587141e..445972462c5e27f948cc1acf8aaff28aa7473f68 100644
--- a/media/audio/audio_manager_base.cc
+++ b/media/audio/audio_manager_base.cc
@@ -95,7 +95,14 @@ AudioManagerBase::AudioManagerBase(AudioLogFactory* audio_log_factory)
   }
 #endif
 
+#if defined(OS_WIN)
+  // We check COM initializer status right after calling this, so wait here

[DaleCurtis, 2015/03/26 00:12:38]

Can you elaborate on why this is necessary? CoreAudioUtil::IsSupported() was
previously running on the UI thread, what piece of code runs after this and
checks the COM status from the UI thread of the audio thread? 

...which as I think about it may not actually be correct. +tommi for his
recollection on why we initialize the device enumerator on the UI thread instead
of the audio thread. I seem to remember some race condition somewhere, but I
don't properly recall.

[DaleCurtis, 2015/04/16 16:41:07]

Did you have a chance to dig into this further? If not do you remember which
tests were failing? I'll try and patch it in today or tomorrow and see why this
is necessary.

+  // until we finish audio thread initialization (where we also run COM
+  // initializer).
+  CHECK(audio_thread_.StartAndWait());
+#else
   CHECK(audio_thread_.Start());
+#endif
   task_runner_ = audio_thread_.message_loop_proxy();
 }