W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: ScriptProcessorNode behavior without JavsScript references

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Thu, 19 Sep 2013 08:27:08 +0300
Message-ID: <CAJhzemUcVnx0UXW8JQXcs9+F-Zb0aFOoeLaWSm83ZWJTBCgCSg@mail.gmail.com>
To: Marcus Geelnard <mage@opera.com>
Cc: Chris Wilson <cwilso@google.com>, Raymond Toy <rtoy@google.com>, "Robert O'Callahan" <robert@ocallahan.org>, "public-audio@w3.org" <public-audio@w3.org>
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 {

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.


> /Marcus
>  -Chris
> --
> Marcus Geelnard
> Technical Lead, Mobile Infrastructure
> Opera Software
Received on Thursday, 19 September 2013 05:27:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:25 UTC