Re: [web-audio-api] Worker-based ScriptProcessorNode (#113)

I can offer a few opinions and thoughts, based on the discussion so far, of course deferring to Chris Wilson where the nature of his proposal is concerned…

> 
> I presume the "scriptURL" argument would be required to support all URL forms referring to a script? In 
> particular, Object URLs? That would be needed to generate scripts on the fly.
> 
> 
This hasn’t been discussed but I also presume/hope this would be OK as it is allowed for regular Web Workers.

> How would lifetime of the node be managed in this case? If this is expected to be garbage collected like 
> other nodes, then perhaps the "terminate()" method exposed in the Worker interface should be hidden? If not, 
> then would terminate() be expected to get rid of the node? What would it do? When should Object URLs passed to nodes be "revoked"?
> 
> 
Great question, and I wonder the same. I’d like to suggest that the same node lifetime apply to such nodes as to any other AudioNodes, based on the audio processing graph properties.

I think that terminate() perhaps does not make sense in this situation and should throw an exception.

I don’t see that Object URLs should be revoked by anything except the application code that created them. I guess I don’t understand why there would be interaction between Object URLs and Web Audio.
> While it is a welcome change to do the js audio processing independent of the main thread, it has always 
> seemed excessive to me to dedicate a worker to each node, especially if browsers are expected to run 
> workers in separate threads, and especially for low cpu usage nodes. () It seems like one shared worker per 
> audio context or per script node type (*) may be better from a system resource perspective
> 

The proposal is that each worker will be run directly in the audio thread to do its work. So there will not be thread-related overhead related to numbers of workers.
> For a script node to function as a usable source node type, instantiation/takedown should be light weight - 
> ex: can be instantiated in predictably short time in response to a key press. Does this design choice limit how 
> light weight it can be?
> 
> I presume the spec will detail how this node is expected to work with offline audio contexts. While I don't see 
> any conceptual issues there right away, I just want to pop into view that these are expected to effectively run 
> synchronously in the case of offline contexts. Lifetime management will also need to be detailed for this case. (Lifetime management of normal nodes for offline contexts still remains an open issue.)
> 
> 
I agree that these should run synchronously for offline contexts, it is the cleanest interpretation. However “synchronously” should refer to whatever thread manufactures the output of an offline context, and until we clean up the offline audio context spec I don’t know if we can completely understand what the consequences of this position are.

> Lastly, it looks like “how to write an onaudioprocess” won’t change with this proposal. So we’re expected to 
> fill the outputBuffer as usual? Is ownership of this buffer is automatically "transferred" to the audio thread 
> afterwards then?
> 
> 
I believe so; Chris, can you clarify?

> (*) It is unclear to me from the WebWorkers spec whether user agents are allowed to share a thread between multiple workers (wording: "or similar construct") and whether current browsers do such things.
> 

I think the fact that audio workers run in the audio thread makes this issue moot.

> (**): By "script node type", I mean script nodes that run a common onaudioprocess function (ex: compressor). Script nodes that depend on common source code can use a shared worker.
> 
> 
Same as above — since they all run (synchronously) within the audio thread, simply having different audio workers running the same script should do the trick, shouldn’t it? Will that not be efficient enough?

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"