Associate audio streams with their source/destination RenderView.

content/common/media/audio_messages.h

Index: content/common/media/audio_messages.h
diff --git a/content/common/media/audio_messages.h b/content/common/media/audio_messages.h
index fd16fbca8dc6067813eac835111738041f9ff472..e78cfddfb8859a8c2bd32b786d7c9a813ab1d249 100644
--- a/content/common/media/audio_messages.h
+++ b/content/common/media/audio_messages.h
@@ -97,6 +97,16 @@ IPC_MESSAGE_CONTROL4(AudioInputHostMsg_CreateStream,
                      std::string /* device_id */,
                      bool /* automatic_gain_control */)
 
+// Indicate that audio for a stream is produced by the specified render view.
+IPC_MESSAGE_CONTROL2(AudioHostMsg_AssociateStreamWithProducer,
+                     int /* stream_id */,
+                     int /* render_view_id */)

[scherkus (not reviewing), 2012/11/27 22:55:26]

Seeing this just jogged my memory.

The history of having unrounted control IPC messages (versus
RenderViewImpl-style routed IPC messages) was due to avoiding signals for
callback/play/pause/flush getting stuck behind render thread messages.

In a world where we use SyncSocket, mixers, etc... most of these messages should
be removed as.

If you squint a bit... you can envision a simpler world where all
audio-stream-related messages are simply part of RenderView[Host]Impl and are
already associated with a RVI because we no longer need the majority of these
IPC calls anymore and the latency of those messages aren't as important.

I don't think we're quite there today (and as such I don't think you should
change the existing approach) ... but I would encourage you to think about it as
a bit of a mental exercise for future planning. I know I'm curious to see how
many of these IPC messages we can remove!

[miu, 2012/11/28 07:26:20]

Agreed.  This is related to the discussion we've been having on
http://crbug.com/151051.

+
+// Indicate that audio for a stream is consumed by the specified render view.
+IPC_MESSAGE_CONTROL2(AudioInputHostMsg_AssociateStreamWithConsumer,
+                     int /* stream_id */,
+                     int /* render_view_id */)
+
 // Start buffering and play the audio stream specified by stream_id.
 IPC_MESSAGE_CONTROL1(AudioHostMsg_PlayStream,
                      int /* stream_id */)