Re: Audio Workers - please review

Globally, the proposal looks rather coherent and feasible to me.

I am not sure if I followed all discussions that led to the "worker"-name for the node, but from my point of view the name is slightly misleading.
Wouldn't be something like "SynchronousScriptProcessorNode" more appropriate?

… or ultimately: Is it really not possible to formalise all this as an option of the "ScriptProcessorNode" (given at creation)?
It already has the right name and the same "onaudioprocess" event.

It seems you me that, following this path, another future extension of the ScriptProcessorNode could be to schedule the "onaudioprocess" events neither in the main thread nor the audio thread but in an arbitrary worker thread.
In neither of these cases the introduced formalisation of audio-rate parameters of the proposed AudioWorkerNode could hurt.
Just that we need a "latency" parameter somewhere (why not writeable or at least configurable) and/or a separate input and output time.

Does that make sense? Or do I miss something essential here?

_____________________
N o r b e r t   S c h n e l l
{ Sound Music Movement } Interaction
IRCAM – Centre Pompidou

On 27 Aug 2014, at 20:28, Chris Wilson <cwilso@google.com> wrote:
> On Wed, Aug 27, 2014 at 11:07 AM, Joseph Berkovitz <joe@noteflight.com> wrote:
> A couple of questions on this idea:
> 
> 1. What about terminate()? Would you support that?
> 
> I'm on the fence.  It would be easier to specify exactly what happens (node input is disconnected from node output, node is pass-through, whatever), so yes.  It's probably valuable to explicitly kill the processing.
>  
> 2. What about any other features that ever get added to Worker in the future? Would we not want those to become visible in  AudioWorker as well?
> 
> I don't know that any other features added to Worker would be interesting to add.  We'd likely need to carefully consider their effects in this case anyway, since the behavior of this type of "worker" is pretty specific to audio.  Short answer, I think, is "no".
>  
> I don’t think the additional nested object is hard to understand, especially since it implements an already familiar interface. Composition is cleaner.
> 
> The model is different from Web Workers usage, where you create an object ("new Worker()"), and then you use that object.  In ServiceWorker, you call an instantiation mechanism ("navigator.serviceWorker.install(....);") and then use the object your promise is resolved with.  Here, if we use a sub-object, we're saying you call an instantation method ("context.createAudioWorker(...)") and then use an object that is a sub-object of the mechanism you're returned (because yes, I definitely agree the worker should be auto-instantiated by the AudioWorkerNode creation).