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

Re: Behavior of source nodes on connect/disconnect

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Fri, 13 Sep 2013 23:52:00 +0300
Message-ID: <CAJhzemV2wopUGOZ4L=Kghiynskyk-Drp5AoXt138v_rMNhb2Og@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Jer Noble <jer.noble@apple.com>, Chris Wilson <cwilso@google.com>, Raymond Toy <rtoy@google.com>, "public-audio@w3.org" <public-audio@w3.org>
On Fri, Sep 13, 2013 at 11:32 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Sep 13, 2013 at 1:31 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Fri, Sep 13, 2013 at 1:26 PM, Jussi Kalliokoski <
>> jussi.kalliokoski@gmail.com> wrote:
>>
>>> I don't really care about using disconnect as pause, it's not meant for
>>> that and it's not a good solution for that. What I care about is what the
>>> use case / justification for having this weirdness is? A nice-to-have (not
>>> sure this is even a nice-to-have) doesn't really warrant introducing hard
>>> to debug memory leaks. I believe a lot of developers will expect that if
>>> they disconnect a ScriptProcessorNode and lose references to it, it gets
>>> GCed and doesn't burn cycles and / or eat away the performance of the graph
>>> anymore. This is similar to disconnecting a DOM node from the graph. If it
>>> has no references, it gets garbage collected and no more events are fired.
>>>
>>
>> That's not true for DOM nodes in general. For example, a completely
>> disconnected HTML media element that's playing some media resource
>> continues to fire events.
>>
>
> I also think it would be bizarre for a developer to connect some audio
> node subgraph to the input of a ScriptProcessorNode for analysis, but not
> get events unless the output of that ScriptProcessorNode is connected to
> the DestinationNode.
>

While I do acknowledge that it is tedious to have to connect analyzer nodes
to the DestinationNode (IIRC I was one of the people pushing for
AnalyzerNode to not have this requirement), I don't think alleviating that
pain point (that can be solved by, well, connecting to the DestinationNode)
is worth the cost.

On the other end there's the tediousness of a ScriptProcessorNode your
module got from another module and you don't know how to make sure it gets
garbage collected. I see that as a much bigger pain point.

Cheers,
Jussi


> 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  *
> *
>
Received on Friday, 13 September 2013 20:52:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:11 UTC