Your argument for the superiority of the Web Audio API seems to be 'it's like Core Audio', and you seem to argue that WebGL is great just because it's like OpenGL. What actually supports this argument? Would you be a big fan of WebDirect3D just because it was exactly like Direct3D? After all, virtually all Windows games and many windows desktop apps use Direct3D, so it must be the best. 3D games on Linux use OpenGL so it must be the best. If you're going to argue that it's good to base web APIs on existing native APIs, why not OpenAL -> WebAL, like OpenGL -> WebGL?
Specs need to be evaluated on the merits. The merits for the Web Audio API at time of release:
* Huge
* Poorly-specified (the API originally specified two ways to load sounds, the simplest of which blocked the main thread for the entire decode! very webby. Spec was full of race conditions from day 1 and some of them still aren't fixed.)
* Poorly-tested
* Large, obvious functionality gaps (you can't pause playback of sounds! you can't stitch buffers together! you can't do playback of synthesized audio at rates other than the context rate!)
* Incompatible with existing <audio>-based code (thanks to inventing a new, inferior way for loading audio assets), making all your audio code instantly browser-specific
* Large enough in scope to be difficult to implement from scratch, even given a good specification (which was lacking)
* A set of shiny, interesting DSP/filter chain features, like convolution and delay and HRTF panning and so on, useful for specific applications
* Basic support for playback and mixing roughly on par with that previously offered by <audio>, minus some feature gaps
The merits for the old Mozilla audio data API at the time of Web Audio's release:
* Extends the <audio> element's API to add support for a couple specific features that solve an actual problem
* Narrow scope means that existing audio code remains cross-browser compatible as long as it does not use this specific API
* The specific features are simple enough to trivially implement in other browsers
You keep making insane leaps like 'Web Audio is good because it's like Core Audio' and 'Mozilla wants you to write DSPs in JavaScript because ... ????' even though there's no coherent logic behind them and there's no evidence to actually support these things. A way to synthesize audio in JavaScript does not prevent the introduction of an API for hardware DSP mixing or whatever random oddball feature you want; quite the opposite: it allows you to introduce those new APIs while offering cross-browser compatible polyfills based on the older API. The web platform has been built on incremental improvement and graceful degradation.
P.S. Even if the Web Audio API were not complete horseshit at the point of its introduction, when it was introduced the Chrome team had sat on their asses for multiple versions, shipping a completely broken implementation of <audio> in their browser while other vendors (even Microsoft!) had support that worked well enough for playing sound effects in games. It's no coincidence that web developers were FORCED to adopt Google's new proprietary API when the only alternative was games that crashed tabs and barely made sound at all.
Isn't the point of introducing something actually getting it fixed from feedback in the WG? So you're complaint is, someone introduced a draft of an idea with a prototype implementation, and you're pissed it wasn't perfect the first time around?
Calling something someone worked on, who happens to be a domain expert, "horseshit" seems a little extreme don't you think? Were not most of the initial problems resolved by WG feedback or not? If yes, they hurray, the WG fulfilled it's purpose. If every feature arrived complete with no problems, there's be little need for a WG, emphasis on the 'W'.
Also "* A set of shiny, interesting DSP/filter chain features, like convolution and delay and HRTF panning and so on, useful for specific applications" Specific, as in, the vast majority of applications. This would be like pissing all over CSS or SVG filters because they don't include a pixel shader spec. 3D positional sound and attenuation are the two features used by the vast majority of games. Neither most applications nor games resort to hand written DSP effects.
As for the <audio> tag playback. Here's a thread where I already had this debate with Microsoft (http://cromwellian.blogspot.com/2011/05/ive-been-having-twit...). Even Microsoft's implementation of <audio> was not sufficient for games or for music synthesis. First of all, their own demo had audible pops because the JS event loop could not schedule the sounds to play on queue. For games like Quake2, which we ported to the Web using GWT, some sound samples were extremely short (the machine gun sound) and were required to be played back-to-back seamlessly as long as the trigger was pulled to get a nice constant machine gun sound. This utterly fails with <audio> tag playback, even on IE (in wireframe canvas2d mode of course). Another port I did, which was a Commodore 64 SID player had the same issue. So let's dispense with the myth that using basic <audio> is sufficient for games. It lacks the latency control to time playback properly even on the best implementation. For Quake2, which features distance attenuation and stereo-positioning,
On the issue of Web Audio / Core Audio, my point there is merely that all of your bashing ignores the point that it is in fact, derived from a mature API that was developed from professional industry requirements over a long time. You keep bashing the built in filters, but those are the tried and true common cases, it's like bashing Porter-Duff blending modes because it's not as general as a shader.
As for Direct3D. You do realize that OpenGL for a long time sucked and was totally outclassed by DirectX? Shaders were introduced by Microsoft. A lot of advanced features arrived on Windows first, because the ARB was absolutely parallelized. So yes, if someone created a "Web3D" API based on Direct3D, it would still be better than Canvas2D, even if you had to write a Direct3D->OpenGL mapping layer. I don't have many bad things to say about DirectX8+, Microsoft did a good job pushing the whole industry forward. DirectX was the result of the best and brightest 3D IHVs and ISVs contributing to it, and so it would be unwise to discount it just because it is proprietary Microsoft.
And Web developers were not forced to adopt Web Audio. For a long time, people used flash shims. In fact, when we shipped Angry Birds for the Web, it used a flash-shim. If Data Audio API lost at the WG, you can't blame Google, people on the WG have free will, and they could have voted down Web Audio in favor of Data Audio, regardless of what Chrome ships.
What I'm hearing in this context however is that you are content in ignoring what most developers wanted. People trying to build HTML5 games needed a way to do the same things people do in games on the Desktop or on consoles with native APIs. The Mozilla proposal did not satisfy these, with no ability to easily do simple things like 3D positioning or distance fallout without dumping in a giant ball of expensive JS into games that developers were already having performance issues with.
Specs need to be evaluated on the merits. The merits for the Web Audio API at time of release:
* Huge
* Poorly-specified (the API originally specified two ways to load sounds, the simplest of which blocked the main thread for the entire decode! very webby. Spec was full of race conditions from day 1 and some of them still aren't fixed.)
* Poorly-tested
* Large, obvious functionality gaps (you can't pause playback of sounds! you can't stitch buffers together! you can't do playback of synthesized audio at rates other than the context rate!)
* Incompatible with existing <audio>-based code (thanks to inventing a new, inferior way for loading audio assets), making all your audio code instantly browser-specific
* Large enough in scope to be difficult to implement from scratch, even given a good specification (which was lacking)
* A set of shiny, interesting DSP/filter chain features, like convolution and delay and HRTF panning and so on, useful for specific applications
* Basic support for playback and mixing roughly on par with that previously offered by <audio>, minus some feature gaps
The merits for the old Mozilla audio data API at the time of Web Audio's release:
* Extends the <audio> element's API to add support for a couple specific features that solve an actual problem
* Narrow scope means that existing audio code remains cross-browser compatible as long as it does not use this specific API
* The specific features are simple enough to trivially implement in other browsers
You keep making insane leaps like 'Web Audio is good because it's like Core Audio' and 'Mozilla wants you to write DSPs in JavaScript because ... ????' even though there's no coherent logic behind them and there's no evidence to actually support these things. A way to synthesize audio in JavaScript does not prevent the introduction of an API for hardware DSP mixing or whatever random oddball feature you want; quite the opposite: it allows you to introduce those new APIs while offering cross-browser compatible polyfills based on the older API. The web platform has been built on incremental improvement and graceful degradation.
P.S. Even if the Web Audio API were not complete horseshit at the point of its introduction, when it was introduced the Chrome team had sat on their asses for multiple versions, shipping a completely broken implementation of <audio> in their browser while other vendors (even Microsoft!) had support that worked well enough for playing sound effects in games. It's no coincidence that web developers were FORCED to adopt Google's new proprietary API when the only alternative was games that crashed tabs and barely made sound at all.