Re: channel layouts and up/down mixing

On Tue, Jan 15, 2013 at 5:50 PM, Ralph Giles <giles@mozilla.com> wrote:

> On 13-01-15 5:21 PM, Ralph Giles wrote:
>
> > But when are the downmix matricies used? There's no clear reference to
> > them other than "for playback". Some more clarity would be useful here.
>
> In anwser to my own question, a number of nodes are defined to accept
> only mono or mono/stereo inputs, so any multichannel inputs connected to
> these nodes would be downmixed. Or upmixed, summed, and downmixed, if
> there are multiple inputs with different channel counts.
>

I'll try to explain more specifically the nodes you might be looking at:

PannerNode:
is hard-coded to stereo (2-channels) and *currently* cannot be configured.
 I'm envisioning that in the future this node could potentially be
configured for other channel layouts, such as 5.1.  This configuration
would be programmatic (perhaps in the createPanner() method) and not break
backwards compatibility because the default would still be stereo, which is
the most common case.

ConvolverNode:
is hard-coded to stereo (2-channels) and *currently* cannot be configured.
 The spec describes the different cases with diagrams.  For >2 channels, I
specifically mention that:
"Without loss of generality, developers desiring more complex and arbitrary
matrixing can use multiple ConvolverNode objects in conjunction with an
ChannelMergerNode."

I *do* believe it would be good to allow ConvolverNode to be configured to
have mono output.  This configuration would not break backwards
compatibility because the default would still be stereo (2-channels), and
the createConvolver() method *could* be extended to specify either 1 or 2
channels, with higher-channel convolutions using multiple ConvolverNodes.

AudioDestinationNode:
has a . numberOfChannels attribute which in all current implementations is
always stereo (2-channels).  It might be a good idea to make this always be
the default, with the potential to increase the number of channels output
programmatically (and not set automatically by the user agent).

AudioParam:
The spec describes automatic down-mixing behavior when an AudioNode is
connected to an AudioParam.  My view is that in normal and useful usage,
developers will be nearly always dealing with mono signals, but the
down-mixing needs to be specified (and is).



>
> A number of these look like attempts to limit initial implementation
> complexity, which means their behaviour would change if these
> restrictions are ever relaxed.
>

They've been designed to have useful default behavior, with the potential
for configuration as I've tried to explain above.

Cheers,
Chris