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

On Sat, May 18, 2013 at 12:59 AM, Frederick Umminger <
frederick.umminger@gmail.com> wrote:

>
>
>
> On Fri, May 17, 2013 at 10:33 PM, Chris Rogers <crogers@google.com> wrote:
>
>>
>> For the web in general, the vast majority of playback systems are stereo.
>>  But, as I said, it's pretty easy to get multi-channel convolution today.
>>  You can try it if you like, since we now support multi-channel output
>> devices  in Chrome.
>>
>
> My point is that the current API does not make it easy to get
> multi-channel convolution. Stereo is directly supported, but 5.1 or 7.1
> require custom code.
>
> The web may be mostly stereo today, but we may as well think about
> tomorrow.
> Your employer has surely thought about bringing the web to the living
> room, with web gaming with full theatrical surround.
> To code out support for that is, IMHO, shortsighted.
>
>
>
>> You make it sound so complicated, but it's really just a few lines of
>> JavaScript.  The "summing junctions" don't even require nodes, since the
>> summing happens automatically by simply making multiple connections to an
>> input:
>>
>> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#UpMix-section
>>
>>  It's just a few lines of code, but if the presentation of the API still
>> bothers you, then it's trivial to wrap this up in a JavaScript object that
>> hides all of these details and gives exactly the API you want.
>>
>
> Yes, it is not that difficult to write. But then neither is most of what
> is in the WebAudio API. The whole point of the API is to make things easy
> and make it so people don't have to write things like this.
>

You're really stretching that argument to the breaking point.  The actual
implementation of many aspects of the Web Audio API, especially the
real-time convolution engine is enormously more difficult, and non-trivial
to write and optimize for multiple platforms than writing a dozen or two
lines of JavaScript to setup arbitrary multi-channel convolution.  In fact,
it's not even feasible with todays generation of processors to write the
convolution from scratch in JavaScript.


>
>
>
>> I've designed the base-level of the API to work well, with little fuss or
>> muss "out of the box" for the vast majority of applications.  And for the
>> advanced applications, it's pretty easy to work it out.
>>
>
> I just disagree with this. In my world, the vast majority of applications
> are surround. The current API does not work "out of the box" with little
> fuss or muss for surround.
>

It's true that surround takes a little more work, but it will always be the
case that authoring for surround takes more work than for stereo.  I ask
that you reserve judgement until more people have had a chance to author
content and applications for surround with the Web Audio API in real life.
 I'm excited to see what they produce, and believe it will not be so hard
as you suggest.


> ConvolverNode does not support surround,
>

It can work with a few lines of code.


> PannerNode does not support surround,
>

This is true, and I'm certainly interested in adding in the ability to
configure it to pan 5.1, etc.  I've done this before in a previous life...


> surround formats are inadequately specified simply by channel count.
>

Yes, there are different channel orderings, etc. in different specific file
formats, but then can be re-ordered by the UA into the canonical ordering
upon decoding.  This is an interesting topic, which probably deserves its
own thread.



>
>
> Sorry if this all sounds negative and critical. I appreciate your work on
> the API.
>

Thanks Frederick, it's good to get the feedback.


>
> But I do want to see it live up to some of the initial aspirations, which
> included things supporting pro audio and DAWs.
> To me, pro audio means, among other things, supporting the formats used in
> theatrical sound, triple-A games, and HDMI.
> And it means being consistent with the scientific literature in the
> related fields such as signal processing and acoustics.
>
> Sincerely,
>     Frederick
>
>
>
>