setTimeout Throttling

Hey Chris,

Thanks for the awesome demo and HTML5Rocks writeup!

You may have considered this already, but I want to point out that Firefox and Chrome (where you'll most likely be using the Web Audio API) throttle setTimeout and setInterval in inactive tabs (http://pivotallabs.com/chrome-and-firefox-throttle-settimeout-setinterval-in-inactive-tabs/).

Truthfully this isn't really a big deal, but if you want your app's scheduling to remain resilient in a background tab or alternate window, it's worth paying attention to. Additionally, reading here (https://developer.mozilla.org/en-US/docs/DOM/window.setTimeout, section "Minimum delay and timeout nesting"), and considering the nested nature of setTimeout calls in this demo, I'm thinking that switching tabs for a second could throw off your scheduling scheme for the remainder of your apps lifetime, right? Which is only really relevant if you're trying to get away with a small lookahead time and strike a balance between setTimeout calls and the block of audio events they're supposed to schedule.

The workaround I've been using for this is to schedule an interval in a WebWorker which calls postMessage back to the main thread appropriately (https://gist.github.com/4551106).

If you think it would be worth it, I'd be happy to implement the WebWorker interaction and send over a pull request. Please let me know if you have a better solution too!