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.

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

var node = audioContext.createScriptProcessorWorker(2048, 1, 1,

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.

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

self.addEventListener('message', function (event) {
    if (event.onaudioprocess) {
        // event.onaudioprocess.inputBuffer,
event.onaudioprocess.outputBuffer, etc....
        // ....


Received on Tuesday, 18 June 2013 07:21:11 UTC