lifetime of AudioWorkerNodes

Hi WG,

I’ve been reviewing the comments in https://github.com/WebAudio/web-audio-api/issues/113 to see what might remain to be addressed in the revised proposal. It feels that a lot of the things folks raised have been addressed, but one interesting point that seems open is a question that Srikumar originally raised about AudioWorkerNode lifetime. I have tried to make some initial observations in this email.

In section 2.3.3 (see http://cwilso.github.io/web-audio-api/#lifetime-AudioNode) there is a summary of the references that figure in determining an AudioNode’s lifetime:

> 	1. A normal JavaScript reference obeying normal garbage collection rules.
> 	2. A playing reference for both AudioBufferSourceNodes and OscillatorNodes. These nodes maintain a playing reference to themselves while they are currently playing.
> 	3. A connection reference which occurs if another AudioNode is connected to it.
> 	4. A tail-time reference which an AudioNode maintains on itself as long as it has any internal processing state which has not yet been emitted.

Let’s consider that any of these cases might apply to an AudioWorkerNode, partly because we expect to be able to implement native nodes with AudioWorkers, but also because these cases represent exactly the kind of custom nodes that devs will expect to build.  Do they all play nice with the current proposal? 

Cases #1 and #3 seem to work fine, because such references are pertinent for any AudioNode, which AWN extends.

Consider case #2 (playing reference for a finite-length source node). Imagine an AWN that simulates something like AudioBufferSourceNode. The start() method can be handled by messaging the node with its AudioContext start time as part of its initialization. It seems that the condition of “while currently playing” can handled by having the AWN’s Worker post a message back to the main thread when the last sample frame of the AWN has been emitted. This message can presumably cause the removal of a “playing” reference to the node from some object in the global scope. (Note: It can’t call terminate() immediately on the node, since there might be extant references to the AWN elsewhere that could revive its operation somehow.)

Case #4 (tail-time reference for a filter-type node) seems tougher. Consider a ConvolverNode AWN simulation simulating reverb with some non-negligible decay time. At first it seems this can be handled the same way as #2, to have the underlying AWN Worker message the fact that it’s done emitting samples due to any internal processing state. But the AWN Worker would first need to know that there are no longer any live upstream nodes feeding data into it, before it can decide to retire that internal state. How could it know that (it can’t examine the node’s numberOfInputs)? Or is it a matter of the worker noting that it’s only seen zeros coming in for some time interval?

One final wrinkle — but this is probably just a question of clarifying the spec. For all these cases, there is a question of whether an AWN's Worker will be automatically terminated when the AWN's lifetime is considered to have ended. I would imagine so, but the proposal doesn’t state this.

What are people’s thoughts on this?

Best,

.            .       .    .  . ...Joe

Joe Berkovitz
President

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