There is no specification for the computation of filter coefficients.
Audio Nodes are subject to garbage collection delays. This effectively makes the API no-go for live performance situations. (I know you can't fix it either.)
Parameter change specifications contain either an analytic or a mutable form, but in practical implementations, both forms become desirable to implement efficient processing that can also begin at arbitrary times within the envelope. I cancelled my implementation of the API after discovering that the lack of detail in this section made for a fragile, confusing, trial-and-error situation to prevent discrepancies when comparing the results of the analytic form against the mutable one.
Rendering does not appear to have any automatic regression test available. Web Audio needs an Acid3-style test.
About the first and third points, it would be great if you can send detailed feedback to this mailinglist: http://lists.w3.org/Archives/Public/public-audio/. Doing that would give us a chance to discuss these issues and fix the spec if possible.
About the second point, that's not accurate. All audio processing in a conforming Web Audio implementation happens on a background thread reserved for audio processing, which does not need to wait for things happening on the main thread (including GC pauses.) In practice, Gecko's processing model uses message passing between the audio thread and the main Javascript thread. WebKit and Blink use locks to synchronize the two threads some of the times, but the locking is minimal and it should not have a huge impact on performance.
I'm not sure how reverting to a lower level JS-driven API could fix the performance issues. High performance audio, like 2D and 3D graphics, needs the ability to offload to native code or dedicated hardware. Writing a DSP in JS makes things portable, but so does writing an OpenGL rasterizer in CPU code. OpenGL to this day still has portability issues between GPUs, but the benefits outweigh the disadvantages.
The only solution is IMHO is to keep finding holes in the spec, driven by feedback from application developers, and plugging the holes.
I don't think a spec/standards committee can fix all of these issues, and like with OpenGL, I suspect, we'll need Web Audio 1.1/1.2/1.3/etc
Absolutely. Feedback from developers testing their applications and ideas with the existing implementations is crucial to having a high quality spec, so if you have specific issues, please provide feedback here: http://lists.w3.org/Archives/Public/public-audio/. We'll definitely take that into consideration and we can always amend the spec based on the feedback we receive to improve things.
Audio Nodes are subject to garbage collection delays. This effectively makes the API no-go for live performance situations. (I know you can't fix it either.)
Parameter change specifications contain either an analytic or a mutable form, but in practical implementations, both forms become desirable to implement efficient processing that can also begin at arbitrary times within the envelope. I cancelled my implementation of the API after discovering that the lack of detail in this section made for a fragile, confusing, trial-and-error situation to prevent discrepancies when comparing the results of the analytic form against the mutable one.
Rendering does not appear to have any automatic regression test available. Web Audio needs an Acid3-style test.