- From: Marcus Geelnard <mage@opera.com>
- Date: Wed, 18 Sep 2013 15:26:23 +0200
- 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>
- Message-ID: <5239A9FF.80509@opera.com>
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). /Marcus > > 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