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

Re: Behavior of source nodes on connect/disconnect

From: Jer Noble <jer.noble@apple.com>
Date: Fri, 13 Sep 2013 13:34:13 -0700
Cc: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Chris Wilson <cwilso@google.com>, Raymond Toy <rtoy@google.com>, "public-audio@w3.org" <public-audio@w3.org>
Message-id: <82C3F4A9-0638-4C9E-8D60-86DBFE0DDEB5@apple.com>
To: Robert O'Callahan <robert@ocallahan.org>

On Sep 13, 2013, at 1: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.

That seems like a valid use case for an OfflineAudioContext.  Why should that developer be rate-limited to 1 second-per-second if they wanted to analyze an entirely disconnected subgraph?


Received on Friday, 13 September 2013 20:34:42 UTC

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