Web Audio API comes to Firefox
hacks.mozilla.org
hacks.mozilla.org
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.
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
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.
We're approaching the stage where we'd like to go to "last call", so there's never been a better time to give us some feedback. Your experience of trying to implement the spec would be very valuable to us.
If you have any questions about getting involved in the group please contact me directly (I co-chair the WG) and I'll help you.
if (typeof AudioContext !== "undefined") { this.context = new AudioContext(); }
It worked without modification, and the audio sounds great so far. In the meantime I'm still falling back to webkitAudioContext for Chrome and Safari until they catch up.
http://matt-diamond.com/drone.html
Haven't gotten a chance to add Firefox compatibility yet (working on it!).
A key problem (and measure of quality) for me is reducing the latency. I've had trouble getting continuous sound with less than a quarter second of buffer. (Ideally, I'd like to achieve smooth sound with only 17ms of buffer/lag). Another browser to work with will help, and, maybe the IE team will take notice.
Timed events is the most important aspect of creating a game or entertainment experience that sounds real to users. I completely took it for granted before I started on this project. Time is quite a rubbery material right now in browsers!
Our mobile & desktop web app, SpeakerBlast, uses the web audio API to play audio in sync across multiple devices.
Though up until now it only works in Chrome & in mobile Safari.
Web apps tend to be really good at very specialized functions. A silly, but I think still valid example would be a meme generator using <canvas> and JS. If you want a picture of a cat with some white Arial text and a black drop shadow, a web app is going to be great. It'll probably be faster than Photoshop (especially if you count startup time), and way more accessible.
Same thing goes for the Web Audio API. Will we see a full-fledged Pro Tools competitor? Probably not. But we will see ringtone generators and voice recorders and (hopefully!) some T-Pain AutoTune apps.
Great web apps are all about playing off the web's strengths, not trying to replicate the desktop.