Remove the AudioManager singleton.

media/audio/audio_output_proxy.cc

Index: media/audio/audio_output_proxy.cc
===================================================================
--- media/audio/audio_output_proxy.cc	(revision 113173)
+++ media/audio/audio_output_proxy.cc	(working copy)
@@ -1,4 +1,4 @@
-// Copyright (c) 2010 The Chromium Authors. All rights reserved.
+// 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.
 
@@ -84,9 +84,14 @@
   DCHECK(state_ == kCreated || state_ == kError || state_ == kOpened);
   DCHECK(!physical_stream_);
 
-  if (state_ != kCreated) {
+  if (state_ != kCreated)
     dispatcher_->StreamClosed();
-  }
-  dispatcher_->message_loop()->DeleteSoon(FROM_HERE, this);
+
   state_ = kClosed;
+
+  // Delete the object now like is done in the Close() implementation of

[henrika (OOO until Aug 14), 2011/12/07 10:08:34]

Have to trust you on this part. Don't know the details well enough to comment
;-)

[tommi (sloooow) - chröme, 2011/12/07 12:26:44]

The Mac, Wave and WASAPI implementations delete themselves by calling
manager_->ReleaseOutputStream(this) and most (or even all?) input stream
implementations use some form of "self_deleter" (see e.g. the Alsa
implementation).

So, the post condition for Close() is that the caller must not touch the object
again. This is also true in the implementation as it was, but instead of
deleting the object straight away, it delayed it by posting a task to the
message queue.  Doing so is however not necessary and has two downsides: It
leaves the door open to flakiness, it can delay shutdown since the message queue
has to keep running in order to delete the task.

+  // physical stream objects.  If we delete the object via DeleteSoon, we
+  // unnecessarily complicate the Shutdown procedure of the
+  // dispatcher+audio manager.
+  delete this;
 }