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

Re: ScriptProcessorNode behavior without JavsScript references

From: Marcus Geelnard <mage@opera.com>
Date: Wed, 18 Sep 2013 15:26:23 +0200
Message-ID: <5239A9FF.80509@opera.com>
To: Chris Wilson <cwilso@google.com>
CC: Raymond Toy <rtoy@google.com>, Robert O'Callahan <robert@ocallahan.org>, "public-audio@w3.org" <public-audio@w3.org>
2013-09-18 15:13, Chris Wilson skrev:
> Well, I suppose the ScriptProcessorNode could itself define its own 
> lifetime, by setting its own onaudioprocess to null (from within the 
> onaudioprocess) - so, for example, if I wished to replicate 
> BufferSourceNode with a ScriptProcessorNode, the SP would play the 
> entire buffer, then (since it has no further work to do) from inside 
> its next onaudioprocess set its onaudioprocess to null, and then 
> (presuming there are no further references held to it) it can be 
> marked for collection, since it's no longer observable.  Yes?

That sounds like a reasonable solution (or it could just disconnect 
itself?). 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). One way could be to add an explicit 
"active" attribute to the node or something (that would be hard to miss 
for developers).


> On Wed, Sep 18, 2013 at 2:50 AM, Marcus Geelnard <mage@opera.com 
> <mailto:mage@opera.com>> wrote:
>     2013-09-17 23:12, Raymond Toy skrev:
>>     On Tue, Sep 17, 2013 at 2:02 PM, Robert O'Callahan
>>     <robert@ocallahan.org <mailto:robert@ocallahan.org>> wrote:
>>         On Wed, Sep 18, 2013 at 8:48 AM, Raymond Toy <rtoy@google.com
>>         <mailto:rtoy@google.com>> wrote:
>>             Let's say you create a ScriptProcessorNode and set the
>>             onaudioprocess to generate, say, a sine wave.  Something
>>             like the script below.
>>             In this case, all Javascript references to the
>>             ScriptProcessorNode and the corresponding onaudioprocess
>>             function are dropped.
>>             What should happen now?  Should you still hear the sine wave?
>>         Yes, otherwise the timing of GC would be observable.
>>     Ok.
>>     And in this particular example, I can't stop the node so the only
>>     way of stopping audio is to close the tab (because the script
>>     node is directly connected to the destination)?
>     Since I'm the author of that particular example, maybe I should
>     clarify... ;-)
>     This example comes from an app I did where I want to have
>     continuous playback of generated audio as long as the tab is open.
>     Even when the output is silence, events should be fired (but only
>     zeros are filled into the buffer).
>     Yes, I expect that you can't delete it or stop it in anyway
>     (otherwise I would have kept a reference to it). I think this is
>     equivalent to other nodes in the graph - they won't be garbage
>     collected just because you drop a reference to them. The main
>     difference, as I see it, is that all nodes (?) except the
>     ScriptProcessorNode have a way of telling the audio engine if they
>     are "done" or not. Thus, the ScriptProcessorNode must be regarded
>     as having an infinite life (right?).
>     /Marcus
>>     Ray
>>         Rob
>>         -- 
>>         Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus
>>         eanuttehrotraiitny  eovni le atrhtohu gthot sf oirng iyvoeu
>>         rs ihnesa.r"t sS?o  Whhei csha iids teoa stiheer :p atroa
>>         lsyazye,d 'mYaonu,r  "sGients  uapr,e tfaokreg iyvoeunr, 'm
>>         aotr  atnod sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n? 
>>         gBoutt  uIp  waanndt wyeonut  thoo mken.o w *
>>         *
>     -- 
>     Marcus Geelnard
>     Technical Lead, Mobile Infrastructure
>     Opera Software

Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software
Received on Wednesday, 18 September 2013 13:26:55 UTC

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