Currently there are several annoyances to scheduling in the Web Audio API. For example, if you want to play back a dynamic sequence, you would power it up with a setTimeout/setInterval, both of which are throttled to once per second when in a background tab. Now, if you set up a timer that happens once per second what happens if a reflow or other event delays the timer? To protect against this, you can schedule events for more than a second at a time, but it's a tradeoff for responsiveness of the application. Responsiveness or robustness is not a nice tradeoff to make.

A suggested approach to this problem has been to add a callbackAtTime() method to the AudioContext, but I fear that introducing yet another timer mechanism to the main thread won't help much. Say you setup a callback to trigger one second from the current time. Should it

a) Fire before the clock actually hits the specified time to be a bit more sure to make it in time?
b) Fire exactly when the clock actually hits the specified time? In this case, the desired target is most likely missed.
c) Fire after the time? This is a ridiculous idea. :D

Anyway, even that would be suspect to being delayed by other main thread events like reflows etc., being not much more reliable than a setTimeout(). I think we're going to get a lot of "no" sound from other working groups and browser vendors if the callbackAtTime() had no throttling rules, when browsers finally have painfully put those restrictions to place for existing main thread timer callbacks, so I don't think we'd get even that advantage.

Hence I'd suggest specifying access to the AudioContext interface from Web Workers, where one doesn't need to worry about main thread events delaying anything, nor about timer throttling.

For the time being, the Workers would obviously support less features (supporting MediaStreamSourceNode and MediaElementSourceNode in the Workers would require transferring these entities to the Worker as well). One option would of course be that AudioContexts would be defined as Transferrables, as well as a AudioNodes, letting graphs be shared across threads. This would probably actually be the best way to achieve this, provided we can eliminate race conditions by having value setters and getters exclusive to the thread that currently has the ownership of each node. But there aren't many critical features like this in the Web Audio API, which makes it a prime candidate for being a Transferrable.