Re: Behavior of source nodes on connect/disconnect

On Sep 13, 2013, at 8:49 AM, Chris Wilson <cwilso@google.com> 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.
> 
> 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.

Sure, but you could always ramp down then disconnect, and ramp up after reconnecting.  If you continue playing while disconnected, you don't even have that option.

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

I'm assume that you meant "you can go ahead and GC them". And no, you can't.  We don't GC active nodes, even ones that no longer have any references to them.  So we would have to distinguish between "active and connected" vs "active and disconnected" nodes.

> 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 to calculate spin up/spin down), if there is any chance the buffer will be disconnected.

But you're doing the disconnecting; it's not something which is done to you.  You already have all the information you need.

And in some respects, we already do this.  Calling audioBufferNode.start(0) doesn't anchor the start time of the AudioBufferNode at 0 in AudioContext time coordinates.  Neither does audioBufferNode.start(ctx.currentTime - 1) skip the first 1s of the buffer. Even calling audioBufferNode.start(ctx.currentTime) doesn't actually do what you want, since ctx.currentTime will have changed value by the time audioBufferNode.start() is called.

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

I don't think so.  We don't provide introspection now for the scenarios i listed above, and authors already have all the information they need to calculate these timeline offsets now.

-Jer