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:26:15 +0300
Message-ID: <CAJhzemWaWJS-kWthnXPqx3rZU6QNeKWffMN6tgs8vtKSET1cTQ@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 10:47 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Sep 13, 2013 at 8:39 AM, Jer Noble <jer.noble@apple.com> wrote:
>> I’m going to have to take up the mantle of Chris and disagree with you
>> strongly here.  Disconnected nodes are disassociated from the graph
>> entirely.  They do not participate in rendering to the destination node,
>> and they no longer are connected to the destination node’s timeline.
> OK, but that's not what the spec currently says and adding that behavior
> to the spec is a large change. So this discussion should really be framed
> as a proposal to make this change to the spec. As such, it would be helpful
> to see the proposed change written down in more detail.
> Philosophically speaking, disconnected nodes are collected by GC because
>> they are no longer active. But if disconnected nodes continue to "play", we
>> would either be GCing active objects, or not GCing disconnected objects,
>> effectively leaking nodes with no end time.  Neither of which are good
>> options.
> In most cases, the ongoing playback of disconnected nodes is not
> observable, and therefore they can be safely destroyed even though they're
> active.
>> Practically speaking, disconnecting a sub-graph is the only way deleopers
>> can "pause" playback. If we force disconnected nodes to continue playing,
>> the only way to pause playback would be to entirely tear down and re-create
>> a subgraph.
> I agree with Chris Wilson; if we're going to support pausing, let's
> support it properly with a pause/resume API.

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.


> Pausing a MediaStream/ElementAudioSourceNode is not a problem. You just
> drop data from the input stream while paused.
> 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:26:42 UTC

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