Pass task runners to AudioManager constructor.

content/browser/browser_main_loop.cc

Index: content/browser/browser_main_loop.cc
diff --git a/content/browser/browser_main_loop.cc b/content/browser/browser_main_loop.cc
index 91fec92c1f173700098640a212dfd70ec612aaa5..b3b14003fd72a049a36aa18a3e27699a57b6a627 100644
--- a/content/browser/browser_main_loop.cc
+++ b/content/browser/browser_main_loop.cc
@@ -1046,6 +1046,9 @@ void BrowserMainLoop::ShutdownThreadsAndCleanUp() {
 #endif
 #endif  // !defined(OS_IOS)
 
+  // Destroy audio_manager_ on audio thread.

[DaleCurtis, 2016/03/18 17:48:18]

Be careful here, this changes the destruction order of AudioManager relative to
it's current position.

[alokp, 2016/03/18 18:40:06]

Yeah I need to cycle this through the trybots.

+  AudioManager::Destroy(audio_manager_.release());
+
   // Shutdown Mojo shell and IPC.
 #if !defined(OS_IOS)
   mojo_shell_context_.reset();
@@ -1256,8 +1259,24 @@ int BrowserMainLoop::BrowserThreadsStarted() {
 
   {
     TRACE_EVENT0("startup", "BrowserThreadsStarted::Subsystem:AudioMan");
-    audio_manager_.reset(media::AudioManager::CreateWithHangTimer(
-        MediaInternals::GetInstance(), io_thread_->task_runner()));
+    scoped_refptr<base::SingleThreadTaskRunner> audio_task_runner;

[DaleCurtis, 2016/03/18 17:48:18]

What will this code look like for cast? 

[alokp, 2016/03/18 18:40:06]

Since BML is common for all platforms/content-embedders, we cannot add any
cast-specific override here. I can think of two options:
1. [Not Good] Rely on BML passing NULL task_runner, which can be overridden in
CastAudioManagerFactory.

2. [Good] Add ContentBrowserClient::GetAudio[Worker]TaskRunner functions that we
can override. This approach is much cleaner. I think you missed one my comments
in AudioManager about making task runners non-optional. Copying it here:

We could make the task_runner arguments mandatory by creating the audio thread
in BrowserMainLoop. But then Cast needs a way to override it. One way to do that
would be to add ContentBrowserClient::GetAudioTaskRunner. The default
implementation will return NULL, in which case BML will create the audio thread.

ContentBrowserClient::GetAudioTaskRunner will work better for us and we will
also avoid the singleton AudioThread class but I am not sure if this function
belongs in ContentBrowserClient. We do have a
ContentBrowserClient::CreateCdmFactory, so maybe?

+    scoped_refptr<base::SingleThreadTaskRunner> worker_task_runner;
+    scoped_refptr<base::SingleThreadTaskRunner> monitor_task_runner;
+    AudioLogFactory* audio_log_factory = MediaInternals::GetInstance();
+#if defined(OS_MACOSX)
+    // CoreAudio calls must occur on the main thread of the process, which in
+    // our case is sadly the browser UI thread. Failure to execute calls on the
+    // right thread leads to crashes and odd behavior.
+    // See http://crbug.com/158170.
+    // Since the audio thread is the UI thread, a hang monitor is not
+    // necessary or recommended.
+    audio_task_runner = base::ThreadTaskRunnerHandle::Get();
+#else
+    monitor_task_runner = io_thread_->task_runner();
+#endif
+    audio_manager_.reset(
+        media::AudioManager::Create(audio_task_runner, worker_task_runner,
+                                    monitor_task_runner, audio_log_factory));
   }
 
   {