From 5ff11135bfe657fab30536b393522ba9b9b9a7bf Mon Sep 17 00:00:00 2001 From: "miu@chromium.org" Date: Tue, 4 Dec 2012 09:53:29 +0000 Subject: [PATCH] Associate audio streams with their source/destination RenderView. This is a first step towards implementing three major Chromium features, all of which need to associate audio outputs with their source tabs. See BUGs referenced by this change for more details. Previous attempt/approach: https://codereview.chromium.org/11166002/ Specifics: 1. Added two new IPC messages: AudioHostMsg_AssociateStreamWithProducer and AudioInputHostMsg_AssociateStreamWithConsumer. 2. Added "associate to render_view_id" IPC calls: PepperPlatformAudioInputImpl, PepperPlatformAudioOutputImpl, RenderAudioSourceProvider, RendererWebAudioDeviceImpl, WebRtcAudioRenderer. 3. AudioOutputDevice instances re-use the same stream IDs. 4. Removed AudioDeviceFactory and replaced test-injection scheme in AudioRendererMixerManager. Not in scope: 1. Associating RenderViews with audio input to WebRTC. 2. Associating RenderViews with streams produced by the AudioRendererMixer. 3. Speech Input (implementation is in the browser process, not the render process). Testing method: Confirm correct render_view_id shows up in debug logging when engaging the various audio code paths. Some of the many test sites used: 1. PPAPI (in and out): http://www.midomi.com/index.php?action=main.mic_check 2. WebMediaPlayer (e.g.,