Re: Behavior of source nodes on connect/disconnect

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

> >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
wubwubwub<http://webaudiodemos.appspot.com/wubwubwub/index.html>to
calculate spin up/spin down), if there is any chance the buffer will
be
disconnected.

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.

-Chris