Need a more algorithmic definition of AudioWorkletNode lifetime

[joeberkovitz]

The definition of lifetime used in the fix to #475 may lack specificity in some way, so WG members have asked to add an issue reflecting the potential need for an algorithmic definition.

[joeberkovitz]

Thought: would it be appropriate to place (or somehow invoke) this algorithmic definition in the Rendering an audio graph section of the spec?

[padenot]

This is orthogonal to rendering: the rendering takes the list of all AudioNodes for a context. This is about removing or adding AudioNodes from a context.

The rendering algorithm is already quite complicated. Maybe it would be best to define something like the "list of AudioNodes of a context" or something equivalent, and have that in the section about life times.

[joeberkovitz]

Oh right. This is about lifetime.

I guess I still don't understand how we should describe a lifetime algorithm for any node at all beyond what we've already said. We have these references defined in the spec, and UAs do garbage collection on any node that lacks references.

[padenot]

We need to define exactly what happens when you render audio for an AudioWorklet. This allow us to get access to the return value of process and do something like the following:

Rendering audio for an AudioWorklet means executing the following steps:

1. If this AudioWorklet does not have a self-reference, make it take a self-reference.
2. Do some prep work, like, take the input data and make Float32Array from them, take the AudioParam data for this render quantum and do the same, etc. This is necessary to spec whether the arrays are reused or not, for example.
3. Call process, and let rv be the return value of this invocation.
4. If rv is true, return from this algorithm
5. Drop the self-reference

At the last step, if the node still has input, it's kept alive. Otherwise, it can be collected.

[joeberkovitz]

I will put together a PR that makes the Lifetime section of AudioNode normative, to resolve this issue.