Some additional requirements for the ScriptProcessorNode ..

>
> I don't think we should try anything like that until the semantics of the
> current setup are properly worked out. Right now the spec is a mess in this
> area and issues already raised have not been addressed.


I presume by "this area", you mean the "dynamic lifetime" part of the spec.
A search for "audiowg lifetime" turned up the following two issues -

Bug 17405 (DynamicLifetime) [1]

Bug 17389 (OfflineAudioContext) [2]

.. and I've also supported using nodes with dynamic lifetimes to model
"voices" in [3].

Problems with the current dynamic lifetime spec -

The main issue with dynamic lifetime as stated in the spec seems to be
Michael Smith's - "This look like a requirement on the implementation, but
it's not normative or detailed enough to test or implement." [1]. The
testability problem is that the spec is talking about what happens to nodes
that are no longer observable to the API user and *may* be visible to the
implementor. The only indirect partial hint available is the
"activeSources" count available from the audio context.

It may not be possible for a node to know about its own reachability in all
GC schemes. This makes it a problem to talk about "references" at all in
the spec. There is an interpretation by Michael given in [1] that addresses
this - "... unless 'has a reference' means 'can produce output' ...".
However, "can produce output" doesn't still take away the requirement that
an object know whether it is reachable from user code. For ex: A gain node
can produce output as long as the API user can connect something to it in
the future and a path to the audio context destination exists or will be
made in the future.

I have not seen a suggested specification yet, and so I attempt a short
version here -

Dynamic lifetime behaviour can simply be this - only inactive orphaned
nodes must be automatically reclaimed by the system. All current native
nodes know whether they are "active" during any given time slice. In
general, a node may determine whether it is active in a time slice based on
- a) whether any of its inputs are active, b) whether it will produce
output for this time slice and c) whether it is scheduled to produce output
in the future. Also, a node with all outputs disconnected is automatically
inactive. A node is considered "orphaned" if it is - 1) not reachable from
JS, 2) not reachable from any other node reachable from JS via its output
and 3) not reachable from any other active node via its output.

The key difference with the current "reference" based spec is that the
current one requires that a node be able to tell whether it will *never*
produce output again, whereas this scheme requires only that a node be able
to determine that for each time slice. The current section on "dynamic
lifetime" which talks about releasing inactive orphaned nodes as early as
possible is then only a performance consideration and an implementation
suggestion. A second such performance consideration would be that inactive
nodes do not consume significant compute cycles.

With this formulation, it also becomes clear what is missing with the
ScriptProcessorNode. A script node cannot determine whether any of its
inputs are active if it needs to base its own active state on that. Its
onaudioprocess would know if it will produce audio for a current or future
time slice, but it has no means of communicating it to the system for the
dynamic lifetime behaviour to kick in. A script node will *not* need to
know about its orphanhood.

Thoughts?

Best,
-Kumar

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17405 (DynamicLifetime)
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17389(OfflineAudioContext)
[3] http://lists.w3.org/Archives/Public/public-audio/2012JulSep/0478.html (mail
thread)

[*] Not entirely sure this is needed.

On Thu, Jan 31, 2013 at 4:10 AM, Robert O'Callahan
<robert@ocallahan.org<javascript:_e({}, 'cvml',
'robert@ocallahan.org');>
> wrote:

> On Wed, Jan 30, 2013 at 6:51 PM, Srikumar Karaikudi Subramanian <
> srikumarks@gmail.com <javascript:_e({}, 'cvml', 'srikumarks@gmail.com');>>wrote:
>
>> 3. Add dynamic lifetime support similar to native nodes,
>>    whereby unreferenced “signal processor” script nodes driven
>>    by source nodes are automatically released once the source
>>    node finishes, even if the source node is itself a script node.
>>    To achieve this, the time at which the inputs cease must
>>    be available as part of the event structure passed to the
>>    onaudioprocess callback, so that the callback can begin
>>    any tail phase that it needs to complete before it commits
>>    suicide.
>>
>
> I don't think we should try anything like that until the semantics of the
> current setup are properly worked out. Right now the spec is a mess in this
> area and issues already raised have not been addressed.
>
> Rob
> --
> Jesus called them together and said, “You know that the rulers of the
> Gentiles lord it over them, and their high officials exercise authority
> over them. Not so with you. Instead, whoever wants to become great among
> you must be your servant, and whoever wants to be first must be your
> slave — just as the Son of Man did not come to be served, but to serve,
> and to give his life as a ransom for many.” [Matthew 20:25-28]
>