[ehsanakhgari]

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.

About the testing issue, the working group has started to work on it recently, and you can see the beginning of the work here: https://github.com/w3c/web-platform-tests/tree/master/webaud.... We're planning to integrate the regression tests from both Mozilla and WebKit into the test suite for the spec (http://mxr.mozilla.org/mozilla-central/source/content/media/... and http://trac.webkit.org/browser/trunk/LayoutTests/webaudio) into the test suite. And of course, contributions for more tests are always welcome.