Plumb render view ID from audio-related code in renderer through IPCs to AudioRendererHost in brows…

content/renderer/renderer_webkitplatformsupport_impl.cc

Index: content/renderer/renderer_webkitplatformsupport_impl.cc
diff --git a/content/renderer/renderer_webkitplatformsupport_impl.cc b/content/renderer/renderer_webkitplatformsupport_impl.cc
index b2b43863331fc0cfa20dab786acb5db6e4c9ae23..3fc8ec446f7f6cc41dde88ebd99c470f82aaf498 100644
--- a/content/renderer/renderer_webkitplatformsupport_impl.cc
+++ b/content/renderer/renderer_webkitplatformsupport_impl.cc
@@ -610,7 +610,11 @@ RendererWebKitPlatformSupportImpl::createAudioDevice(
       media::AudioParameters::AUDIO_PCM_LOW_LATENCY, layout,
       static_cast<int>(sampleRate), 16, bufferSize);
 
-  return new RendererWebAudioDeviceImpl(params, callback);
+  // TODO(miu): This method should be moved to RenderViewImpl.  First, a WebKit
+  // change must land: https://bugs.webkit.org/show_bug.cgi?id=92718
+  // This issue is being tracked in http://crbug.com/156535.  For now, a stub:
+  static const int kUnknownRenderViewId = -1;
+  return new RendererWebAudioDeviceImpl(kUnknownRenderViewId, params, callback);

[jamesr, 2012/10/29 22:51:02]

I think this is not quite the right way to plumb this.  When you create an audio
device, it shouldn't really care about what render view ID it's associated with
- you really only care when you are going to play sound (i.e. the
WebAudioDevice::start() call).

I think the way to plumb this is to look at how web sockets work.  The lifecycle
there is something like this:
1.) WebKit creates a WebSocketStreamHandle via
Platform::createSocketStreamHandle().  The object is constructed on the chromium
side
2.) when WebKit's ready to use the socket, it calls
WebFrameClient::willOpenSocketStream(WebSocketStreamHandle*).  The chromium
implementation of this uses this call to associated the implementation of
WebSocketStreamHandle with the context of the WebFrame (which is associated with
a view, etc).
3.) WebKit uses the WebSocketStreamHandle to do whatever it likes and the
chromium side has the metadata associations it needs.

We really do not want to make WebKit directly aware of RenderViewIds.  It's not
a concern of WebKit how these things are hooked up and it doesn't impact the
operation of WebKit at all.  Instead, we should keep metadata associations like
this contained on the chromium side and use callbacks to associate state that we
need.

 }
 
 //------------------------------------------------------------------------------