Re: Reconciling ConvolverNode's output channel dependencies with the mixing rules in the spec

On Thu, May 16, 2013 at 4:05 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>
 wrote:

> On Thu, May 16, 2013 at 5:37 PM, Chris Rogers <crogers@google.com> wrote:
>
>>
>>
>> Actually, the way I'd describe it (and the way WebKit/Blink implements
>> it) is that the output is hard-coded to 2-channels (stereo) very much in
>> the same way that PannerNode is.  We should add the text:
>>
>> "The output of this node is hard-coded to stereo (2 channels) and
>> currently cannot be configured"
>>
>> That means that the "Mono" case in the diagram currently never happens
>> and that "Mono to copied Stereo" is used when N=1,K=1
>>
>
This does not make sense to me. Why would we be hard-coding an assumption
of stereo here?
Convolution can be used for any number of inputs and outputs.
And it will be used with multiple outputs for surround reverb support. We
are supporting surround, right?
It will also probably be used to implement unexpected effects other than
reverbs.

If a channel assumption had to be hardcoded for output, the assumption
should be a mono output since mono channels can be combined to get the
general case.

The way this should work is that a ConvolverNode converts N inputs to M
outputs and there must be K=N*M impulses.
K should not be independently settable, because no other value makes sense
for what is essentially a matrix multiplication.
Any value other than K=N*M is an error, or reflects some particular
non-general assumption.
If M does not match the number of inputs to the next node, then down- or
up- mixing happens after the convolution effect.

Sincerely,
    Frederick