ScriptProcessorNodes and WebWorkers

Thanks for defining these cool audio interfaces!

PROBLEM: I want to implement a particularly CPU intensive
ScriptProcessorNode, and have it not block the main event loop.

I'd suggest that having audio processing not run on the main
event-loop/thread/core might be the preferred way to structure an
application that both has UI and processes audio, and the
ScriptProcesorNode API would do well to encourage this sort of structure.

A FEW IDEAS:
1) Define a ScriptProcessorWorker which receives an onaudioprocess event
(in addition to the standard-for-web-worker 'message' event)

app.js:
var node = audioContext.createScriptProcessorWorker(2048, 1, 1,
'my-worker.js');

my-worker.js:
self.addEventListener('onaudioprocess', function (event) {
   // ... event.inputBuffer, event.outputBuffer, etc are available
});

2) Allow the entire AudioContext to be instantiated inside a Worker (or
possibly a special AudioWorker), instead of on the main event loop. Since
an audio chain ideally doesn't coordinate between multiple threads, this
might be a preferred way to handle an AudioContext, whereas idea (1) might
require browser vendors to implement relatively-more-complex and less
performant cross-thread synchronization.

3) Requiring less involvement with the Web Worker specification, but
creating a less desirable API: allow a ScriptProcessor to designate a
regular Worker to receive audio data, and define a standard message format,
PARTICULARLY defining the semantics of handing the sample buffer back and
forth as a Transferable, to permit zero-copy processing.

app.js:
var node = audioContext.createScriptProcessor(2048, 1, 1);
node.worker = new Worker('my-worker.js');

my-worker.js:
self.addEventListener('message', function (event) {
    if (event.onaudioprocess) {
        // event.onaudioprocess.inputBuffer,
event.onaudioprocess.outputBuffer, etc....
        // ....
        event.onaudioprocess.done();
    }
});

-Seth