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.