Plumb |input_channels| all the way to AudioManager

Plumb |input_channels| all the way to AudioManager
to support synchronized audio I/O without requiring use of the
"Web Audio Input" enable flag.

The approach taken is to include |input_channels| as part of the AudioParameters
class so that we can represent synchronized I/O streams directly without needing to separately
pass |input_channels| through-out the callstack.

Please note that we're still not yet removing the "Web Audio Input"
flag until we more properly verify the input device selection from getUserMedia().

BUG=none
TEST=manual test: http://chromium.googlecode.com/svn/trunk/samples/audio/visualizer-live.html
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=181126

[Chris Rogers, 2013-01-15 02:19:46]

I haven't yet finished the yak shaving (all platforms, unit tests...), but
wanted to give you guys an early look.

Henrik, we'll need to make changes to AudioManagerWin similar to what I've done
for AudioManagerMac.

[Chris Rogers, 2013-01-16 02:15:57]

Finished yak shaving - PTAL

[henrika (OOO until Aug 14), 2013-01-16 11:17:16]

Sorry, have some basic questions first.

From the client:

RendererWebAudioDeviceImpl::RendererWebAudioDeviceImpl(
    const media::AudioParameters& params,
    int input_channels,
    WebAudioDevice::RenderCallback* callback)
    : params_(params),
      input_channels_(input_channels), <<===
      client_callback_(callback) {
  DCHECK(client_callback_);
}

we then spread usage of input_channels_ all the way down to the browser where it
lands in the audio manager:

if (input_channels == 2 && CommandLine::ForCurrentProcess()->HasSwitch(...

and then creates a special audio backend class for this case.

Questions:

- What exactly sets input_channels in the RendererWebAudioDeviceImpl() ctor?
- Why is it called input_channels and "== 2" means what actually? What does 0
and 1 mean?
- It is still not clear to me how the audio parameters above can be used in
cases where in and out uses different settings (e.g. sample rate and channel
config). How shall the best set be determined then?

[Chris Rogers, 2013-01-16 18:33:57]

On 2013/01/16 11:17:16, henrika wrote:
> Sorry, have some basic questions first.
> 
> From the client:
> 
> RendererWebAudioDeviceImpl::RendererWebAudioDeviceImpl(
>     const media::AudioParameters& params,
>     int input_channels,
>     WebAudioDevice::RenderCallback* callback)
>     : params_(params),
>       input_channels_(input_channels), <<===
>       client_callback_(callback) {
>   DCHECK(client_callback_);
> }
> 
> we then spread usage of input_channels_ all the way down to the browser where
it
> lands in the audio manager:
> 
> if (input_channels == 2 && CommandLine::ForCurrentProcess()->HasSwitch(...
> 
> and then creates a special audio backend class for this case.
> 
> Questions:
> 
> - What exactly sets input_channels in the RendererWebAudioDeviceImpl() ctor?

WebAudio does.  The input_channels will be 0 most of the time, except when used
with getUserMedia().  More specifically when a MediaStreamAudioSourceNode is
created from a getUserMedia() MediaStream.

This is part of a larger change to improve efficiency of this code path (and
remove the flag) so that we don't process live audio input unless we really need
to:
http://trac.webkit.org/changeset/139262
http://trac.webkit.org/changeset/139678
https://codereview.chromium.org/11827040/

> - Why is it called input_channels and "== 2" means what actually? What does 0

This is just a temporary limitation for OSX because the back-end has some
hard-coding to stereo.  If this is not the case for Windows, then we can change
it to >0 in AudioManagerWin

> and 1 mean?
> - It is still not clear to me how the audio parameters above can be used in
> cases where in and out uses different settings (e.g. sample rate and channel
> config). How shall the best set be determined then?

The way it works on OSX is that the sample-rate is driven off the output side,
and the input is sample-rate converted to that.  This happens at a low-level in
the OSX AudioOutputStream impl, so there's no need to have "params" associated
with the input.  Concerning different channel configs, we should make that work,
although OSX is currently limited to 2 channels for both input/output.  The
information in the AudioParameters gives output channels, and now we have input
channels, so we have all the info we need.  The SyncReader, etc. should already
be working for this scenario.

[DaleCurtis, 2013-01-16 21:41:51]

Hmm, if you made input channels a settable AudioParameters field, this change
would just be a few lines, no? As we discussed via chat, I think it might be
worth considering that rather than committing this.

[Chris Rogers, 2013-01-16 22:46:27]

On 2013/01/16 21:41:51, DaleCurtis wrote:
> Hmm, if you made input channels a settable AudioParameters field, this change
> would just be a few lines, no? As we discussed via chat, I think it might be
> worth considering that rather than committing this.

By "settable" you mean it wouldn't be required by the AudioParameters
constructor (which would initialize it to zero?)

[DaleCurtis, 2013-01-17 01:22:03]

Yes, or making it an optional constructor argument.

[Chris Rogers, 2013-02-05 22:24:59]

Dale, I've re-worked this as you suggest by including the |input_channels| as
part of the AudioParameters class.  PTAL :)

[DaleCurtis, 2013-02-05 22:55:05]

lgtm

[Chris Rogers, 2013-02-05 23:12:30]

jam: for content approval

[jam, 2013-02-06 07:21:56]

lgtm