W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2016

Re: Node lifetime question

From: Joe Berkovitz <joe@noteflight.com>
Date: Tue, 4 Oct 2016 11:32:19 -0400
Message-ID: <CA+ojG-bxPnqWztgyUA0QPEESRChtNrgmv9WMLtE=wzOiRwg-OA@mail.gmail.com>
To: Paul Adenot <padenot@mozilla.com>
Cc: Raymond Toy <rtoy@google.com>, Audio Working Group <public-audio@w3.org>
I agree with this outcome, but the reasoning still feels murky. It seems
that you are saying that an active connection from some source to some node
via an AudioParam doesn't count as an "input reference" to keep it alive,
but a connection via its input does. Perhaps that's true, but I want to
make sure.

Let's try this example. In this one, there are three nodes: two oscillators
and a GainNode. One oscillator is being amplified, the other is modulating
the gain node. The source oscillator becomes stopped and has no JS
references, but the modulation oscillator sticks around. Does the GainNode
stick around too?

  var mod = new OscillatorNode(...); // modulation source
  var sig = new OscillatorNode(...);  // signal source
  sig.connect(amp);
  var amp = new GainNode();
  mod.connect(amp.gain);
  amp.connect(ctx.destination);
  mod.start();
  sig.start();
  sig.stop(ctx.currentTime + 1);
  sig = null;  // note: mod is still playing, and is also retained by a JS
reference

Question: does the gain node `amp` remain in the graph or can it be GCed?


.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC

+1 978 314 6271

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Tue, Oct 4, 2016 at 4:21 AM, Paul Adenot <padenot@mozilla.com> wrote:

> Agreed with Raymond here.
>
> Paul.
>
> On Tue, Oct 4, 2016 at 12:20 AM, Raymond Toy <rtoy@google.com> wrote:
>
>> Once oscB has stopped, and because you've dropped all references to both
>> A and B, does it matter anymore?  Nothing is observable anymore and you
>> can't make them observable, so it seems to me we don't have to say
>> anything.  The implementation can do whatever it wants now.
>>
>> On Mon, Oct 3, 2016 at 8:04 AM, Joe Berkovitz <joe@noteflight.com> wrote:
>>
>>> But in that case, A and B both have "playing" references as per the
>>> Lifetime section of the spec, so JS references are irrelevant.
>>>
>>> So here is an improved and hopefully more troubling statement of the
>>> question:
>>>
>>> Let's say that osc A is modulating the frequency of osc B, but that B
>>> reached its stop time (and A has no stop time). Would we keep B alive
>>> anyway, because retained node A is modulating it, in spite of the fact that
>>> B can only produce silence?
>>>
>>> Example:
>>>   var oscA = new OscillatorNode(...);
>>>   var oscB = new OscillatorNode(...);
>>>   oscA.connect(oscB.frequency);
>>>   oscB.connect(ctx.destination);
>>>   oscA.start();
>>>   oscB.start();
>>>   oscB.stop(ctx.currentTime + 1);
>>>   oscA = oscB = null;
>>>
>>>
>>> .            .       .    .  . ...Joe
>>>
>>> Joe Berkovitz
>>> President
>>> Noteflight LLC
>>>
>>> +1 978 314 6271
>>>
>>> 49R Day Street
>>> Somerville MA 02144
>>> USA
>>>
>>> "Bring music to life"
>>> www.noteflight.com
>>>
>>> On Fri, Sep 30, 2016 at 7:18 PM, Raymond Toy <rtoy@google.com> wrote:
>>>
>>>> I think it should.  If A and B are both oscillators and A is connected
>>>> to, say, B.frequency, I expect to hear the modulated B even if A and B have
>>>> no Javascript references to them.
>>>>
>>>> On Fri, Sep 30, 2016 at 1:22 PM, Joe Berkovitz <joe@noteflight.com>
>>>> wrote:
>>>>
>>>>> I sat down to work on https://github.com/WebAudio/we
>>>>> b-audio-api/issues/944 and discovered a question.
>>>>>
>>>>> So: we already know (I think) that when AudioNode A's output is
>>>>> connected to AudioNode B's input, then A has a "connection reference" to B.
>>>>> Thus, if A is retained, B is retained too.
>>>>>
>>>>> But what about the case where AudioNode A is connected to an
>>>>> AudioParam exposed by AudioNode B? Does A keep B alive in this case?
>>>>>
>>>>> .            .       .    .  . ...Joe
>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Tuesday, 4 October 2016 15:32:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 October 2016 15:32:54 UTC