MediaStream audio object graph untangling and clean-ups.

content/renderer/media/webrtc_audio_device_impl.h

Index: content/renderer/media/webrtc_audio_device_impl.h
diff --git a/content/renderer/media/webrtc_audio_device_impl.h b/content/renderer/media/webrtc_audio_device_impl.h
index a3bbf6b8ee7f362b696f0911bc66509d78317cc7..49ef691b4d3d782602ddc98088cd87146bc6f6cc 100644
--- a/content/renderer/media/webrtc_audio_device_impl.h
+++ b/content/renderer/media/webrtc_audio_device_impl.h
@@ -7,6 +7,7 @@
 
 #include <stdint.h>
 
+#include <list>
 #include <string>
 #include <vector>
 
@@ -306,15 +307,12 @@ class CONTENT_EXPORT WebRtcAudioDeviceImpl
   // Called on the main renderer thread.
   bool SetAudioRenderer(WebRtcAudioRenderer* renderer);
 
-  // Adds/Removes the capturer to the ADM.
+  // Adds/Removes the |capturer| to the ADM.  Does NOT take ownership.
+  // Capturers must remain valid until RemoveAudioCapturer() is called.

[o1ka, 2016/02/29 14:28:04]

How will we prevent bugs cause by violation of this contract? What is the
benefit of this change?

[miu, 2016/03/01 09:43:55]

The risk of that is non-existent here because the interaction is simple:
WebRtcAudioCapturer registeres itself with WebRtcAudioDeviceImpl when it is
constructed (in Initialize()), and de-registers itself when it is stopped
(before destruction).  Therefore, the pointer that WebRtcAudioDeviceImpl has is
never invalid.

I may not be understanding your question entirely, but it's worth noting that
ref-counting is not a mechanism we should use to guarantee contracts like this. 
The Chromium project does numerous things in the waterfall tests (vtable
clobbering at destruction, ASAN test runs, etc.) to confirm we're not
accidentally accessing an object after it has become invalid.

As for benefits:

1. The Chromium project is always trying to eliminate the use of ref-counting as
much as possible.  See
https://www.chromium.org/developers/smart-pointer-guidelines (search for
"Ref-counted objects" for technical discussion).

2. By removing the ref-counting here, I've made it clear which is the one object
that owns a WebRtcAudioCapturer (the MediaStreamAudioSource) and therefore it is
also clear how long the object will remain alive and when the object will be
torn-down.  In my next CL, I'll leverage this to cleanly factor-out the reusable
components from the WebRTC-specific ones.

[o1ka, 2016/03/01 14:18:59]

Thanks a lot for the detailed reply - it answers exactly the question I asked
and is very helpful (a very nice article you referenced, it clarified some
things for me - thank you!).

   // TODO(xians): Remove these two methods once the ADM does not need to pass
   // hardware information up to WebRtc.
-  void AddAudioCapturer(const scoped_refptr<WebRtcAudioCapturer>& capturer);
-  void RemoveAudioCapturer(const scoped_refptr<WebRtcAudioCapturer>& capturer);
-
-  // Gets the default capturer, which is the last capturer in |capturers_|.
-  // The method can be called by both Libjingle thread and main render thread.
-  scoped_refptr<WebRtcAudioCapturer> GetDefaultCapturer() const;
+  void AddAudioCapturer(WebRtcAudioCapturer* capturer);
+  void RemoveAudioCapturer(WebRtcAudioCapturer* capturer);
 
   // Gets paired device information of the capture device for the audio
   // renderer. This is used to pass on a session id, sample rate and buffer
@@ -331,7 +329,7 @@ class CONTENT_EXPORT WebRtcAudioDeviceImpl
   }
 
  private:
-  typedef std::list<scoped_refptr<WebRtcAudioCapturer> > CapturerList;
+  typedef std::list<WebRtcAudioCapturer*> CapturerList;
   typedef std::list<WebRtcPlayoutDataSource::Sink*> PlayoutDataSinkList;
   class RenderBuffer;