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

Re: Behavior of source nodes on connect/disconnect

From: Chris Wilson <cwilso@google.com>
Date: Fri, 13 Sep 2013 08:49:41 -0700
Message-ID: <CAJK2wqWOT0EH5mOGKr2Xnb8-FUtw2LhQQW_7Dm80WyLyivzX+g@mail.gmail.com>
To: Jer Noble <jer.noble@apple.com>
Cc: Raymond Toy <rtoy@google.com>, "public-audio@w3.org" <public-audio@w3.org>
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.
> There are philosophical and practical reasons for this.

Fair enough...

> 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.
> 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.

This is a crappy, crappy way to pause playback.  It does not always work
that way - for example, I'm willing to bet you're not suggesting we buffer
up live input from a getUserMedia stream while the resulting graph is
disconnected (nor perhaps even a MediaElement stream).  There's no
fade-in/out, and no persistent level (since it's disconnected) so you're
likely to get a pop.

Note that you wouldn't be "not GCing objects" because they're (silently)
playing - if you have a reference to them, you need to keep them around
anyway; if you DON'T have a reference to them, there's no way you could
ever reconnect them, so you can go ahead and reconnect them.

Hmm, that does mean onended should only fire if they're connected; my bad

> >A different scenario:  You've started playing a source node, and then
> completely disconnect it from the graph and then add a onended listener.
>  What should happen? Does the onended listener get called when the source
> would normally end?
> If you've added an onended listener, that keeps the node alive, and it
> would fire when the node finished playing (despite it having been
> disconnected previously).
> No, itís timeline is not progressing, so it does not emit a Ďendedí event.

This concept of a timeline that is subgraph-dependent is what concerns me.
 It means you cannot, for example, just use simple math to figure out where
playback is on a bufferSource (like what I do in
calculate spin up/spin down), if there is any chance the buffer will

At the very least, the concept of different timelines for subgraphs would
need to be detailed; personally, I think then you'd end up needing to
provide some introspection into those timelines too.

Received on Friday, 13 September 2013 15:50:13 UTC

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