Associate audio streams with their source/destination RenderView.

content/common/media/audio_messages.h

 // Copyright (c) 2012 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.
 
 // IPC messages for the audio.
 // Multiply-included message file, hence no include guard.
 
 #include <string>
 
 #include "base/basictypes.h"
@@ skipping 79 matching lines @@
                      media::AudioParameters, /* params */
                      int /* input_channels */)
 
 // Request that got sent to browser for creating an audio input stream
 IPC_MESSAGE_CONTROL4(AudioInputHostMsg_CreateStream,
                      int /* stream_id */,
                      media::AudioParameters /* params */,
                      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 */)
 
 // Start recording the audio input stream specified by stream_id.
 IPC_MESSAGE_CONTROL1(AudioInputHostMsg_RecordStream,
                      int /* stream_id */)
 
 // Pause the audio stream specified by stream_id.
 IPC_MESSAGE_CONTROL1(AudioHostMsg_PauseStream,
@@ skipping 20 matching lines @@
 // Set audio volume of the input stream specified by stream_id.
 IPC_MESSAGE_CONTROL2(AudioInputHostMsg_SetVolume,
                      int /* stream_id */,
                      double /* volume */)
 
 // Start the device referenced by the session_id for the input stream specified
 // by stream_id.
 IPC_MESSAGE_CONTROL2(AudioInputHostMsg_StartDevice,
                      int /* stream_id */,
                      int /* session_id */)