>Web Audio API has a similar mechanism for generating samples with JS and it's just as bad. In fact, Web Audio is worse for playback of JS-synthesized audio, not better. And lots of use cases demand playback of JS-synthesized audio: emulators, custom audio codecs, synths, etc.

Generating audio samples via JS is an escape hatch, the same way rasterizing to a raw framebuffer is an escape hatch. If your system had audio acceleration hardware, and many systems do (e.g. DirectSound/OpenAL), you want to leverage that.

If you are deploying a game to a mobile device, the last thing you want to do is waste CPU cycles burning JS to do DSP effects in software. This is especially awful for low end phones like the ones that Firefox OS runs on. Latency on audio is already terrible, you don't want the browser UI event loop involved IMHO in processing it to feed it. Maybe if you had speced it being available to Web Workers without needing the UI thread involved it would make more sense.

>The Web Audio API introduced an interconnected web of dozens of poorly tested, poorly specified components that covered some arbitrary subset of cases users care about

The arbitrary subset being, those that have been on OSX for years? AFAIK, Chris Rogers developed Web Audio based on years of experience working on Core Audio at Apple, and therefore, at minimum, it represents at least some feedback from the use cases of the professional audio market, at the very least, Apple's own products like Garage Band and Logic Express which sit atop Core Audio.

You assert that the other use cases could have been handled by just extending existing APIs, but to me this argument sounds like the following:

"You've just dumped this massively complex WebGL API on us, it has hundreds of untested functions. It would be better to just have <canvas> or <img> with a raw array that you manipulate with JS. Any other functions could be done [hand-wave] by just bolting on additional higher level apis. Like, if you want to draw a polygon, we'd add that."

APIs like Core Audio, Direct Sound, OpenGL have evolved because of low level optimization to match the API to what the hardware can accelerate efficiently. In many cases, bidirectional, so that HW influences the API and vice-versa. Putting the burden on the WG to reinvent what has already been done for years is the wrong way to go about it. Audio is a solved problem outside JS, all that was needed was good idiomatic bindings for either Core Audio, OpenAL, or DirectSound.

Whenever I see these threads on HN, I always get a sense of a big dose of NIH from Mozilla. Whenever anyone else proposes a spec, there's always a complaint about complexity, like Republicans complaining about laws because they are too long, when in reality, they don't like them either for ideological reasons, or political ones.

Mozilla is trying to build a web-based platform for competing with native apps. You can see it in asm.js and Firefox OS. And they are not going to get there if they shy away from doing the right things because they are complex. Mobile devices need all the hardware acceleration they can get, and specing out a solution that requires JS to do DSP sound processing is just an egregious waste of battery life and cycles IMHO for a low end web-OS based mobile HW.