Re: Web Audio API Proposal

That API looks extremely complicated. It looks like it will be a huge amount
of work to get a precise spec with interoperability across diverse
implementations.

Dave Humphrey's proposed API ( https://wiki.mozilla.org/Audio_Data_API ) is
far simpler because it leaves almost all audio processing to JS. This "Web
Audio API" proposal has a section "Javascript Issues with real-time
Processing and Synthesis:" which lists several problems, but they boil down
to two underlying issues:
1) JS is slower than native code.
2) Processing audio on a Web page's "main thread" has latency risks.

Issue #2 can be addressed by extending the Audio Data API so it can be used
from Web Workers.

For issue #1, there is experimental data showing that many kinds of effects
can be done "fast enough" in JS. See the Audio Data API demos, and
https://bugzilla.mozilla.org/show_bug.cgi?id=490705#c49 for some performance
numbers. Certainly there's still a performance gap between current JS
implementations and hand-vectorized code, but it seems to me more profitable
to work on addressing that gap directly (e.g. improving JS implementations,
or adding vector primitives to JS, or providing a library of standard signal
processing routines that work on WebGLArrays, or even NaCl/PNaCl) than
hardcoding a ton of audio-specific functionality behind a complex API. The
latter approach will be a lot more work, not reusable beyond audio, and
always limited, as people find they need specific effects that aren't yet
supported in the spec or in the browser(s) they want to deploy on.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]