Re: ScriptProcessorNode behavior without JavsScript references

On Wed, Sep 18, 2013 at 5:28 PM, Marcus Geelnard <mage@opera.com> wrote:

>  2013-09-18 15:38, Chris Wilson skrev:
>
> On Wed, Sep 18, 2013 at 6:26 AM, Marcus Geelnard <mage@opera.com> wrote:
>
>>  That sounds like a reasonable solution (or it could just disconnect
>> itself?).
>>
>
>  Yes, presumably you could just disconnect yourself, and that would cause
> the onaudioprocess to stop being called (and thus release observability).
>
>   In any event I think that we need to clearly instruct developers to
>> signal the death of ScriptProcessorNodes, or they could leak like mad (e.g.
>> if you create one ScriptProcessorNode per note played in a MIDI
>> application).
>>
>
>  Yep, that's the major concern here.  I foresee LOTS of leaky SP
> scenarios.
>
>
>>  One way could be to add an explicit "active" attribute to the node or
>> something (that would be hard to miss for developers).
>>
>
>  But they won't be checking them - because they won't have references
> anymore.  :)
>
>
> You'd do it from the onaudioprocess event. I just figured it would be
> clearer to have an appropriately named attribute than to have to use
> disconnect or nulling the event handler.
>
> Also, I have a feeling that it's a better idea to let the audio engine
> decide when it's time to disconnect a node than leaving it up to a single
> node in the graph. For instance, a ScriptProcessorNode with zero tail
> effects (e.g. a gain) could say "I'm idle" immediately, but without knowing
> if all of it's inputs are idle it shouldn't really disconnect itself.
> Otherwise you have to rely on input data analysis and heuristics (that can
> obviously fail).
>

I'd say *will* fail. And not only that, but if a SP node disconnects itself
or removes its onaudioprocess event when it detects that it is idle, and JS
still *has* a reference to the node and connects something new there, the
node is already dead, which is undesirable.

What about we introduce "type" for SP nodes? e.g.

enum ScriptProcessorNodeType {
  "destination",
  "source",
  "modifier"
}

This way the SP nodes could tell the audio engine what kind of heuristics
to apply:

destination: this type doesn't *need* outputs, but if it is connected to an
output, it will pass through its input to its output. This node becomes
idle when it has no active sources. Examples: AudioDestinationNode,
MediaStreamAudioDestinationNode and AnalyserNode.
source: this type ignores its inputs. This node becomes inactive if it
produces silence for a longer period of time. Examples:
MediaStreamAudioSourceNode, OscillatorNode and AudioBufferSourceNode.
modifier: this type needs both inputs and outputs to function. This node
becomes idle if all its inputs are idle and it produces silence for a
longer period of time. Examples: WaveShaperNode, DelayNode, ConvolverNode,
BiquadFilterNode, etc.

Or can we use heuristics to detect these? I think it would be better if the
nodes can declare their intent.

Cheers,
Jussi



> /Marcus
>
>
>  -Chris
>
>
>
> --
> Marcus Geelnard
> Technical Lead, Mobile Infrastructure
> Opera Software
>
>