Re: Behavior of source nodes on connect/disconnect

On Fri, Sep 13, 2013 at 9:39 AM, K. Gadd <kg@luminance.org> wrote:

> On Fri, Sep 13, 2013 at 8:49 AM, Chris Wilson <cwilso@google.com> wrote:
>
>> 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.
>>
>
> Re: this, if onended fired on a disconnected node it would allow you to
> 'recover' or 'resurrect' a dead (no live references in JS heap) node by
> pulling the this-reference/event target out of the event arguments in the
> onended handler. If the onended handler happened to be getting fired by a
> GC finalizer... that would be pretty bad.
>

Yep, that's what prompted that comment.


> On the other hand, that does put us back in the spot where onended doesn't
> fire sometimes, and I thought people had voiced strong opinions that it
> should always fire.
>

In that case (sorry, convenient amnesia of that discussion), onended could
fire when the references are dropped.  But seriously, I think the case of
"I have no remaining references to a node, but I still expect onended to
fire" has got to be awfully narrow.

Also, in the past I saw strong statements from either cwilson or crogers
> (sorry, I don't remember which) to the effect that pausing was
> intentionally not supported in the design of the Web Audio API, explicitly
> *because* it doesn't make sense in the patch cable model - so it's weird to
> see the opposite stated now based on the same justification. IIRC the
> justification used at the time was that an effect pedal or recorder or
> mixer is not going to suddenly 'pause' functioning because of a cable being
> disconnected, and I do agree with that logic. (Though the idea of
> constraining a games/multimedia realtime mixing API in order to be 'like
> hardware' is pretty odd to me)
>

That was likely me, as the patch cable model has been my natural model. But
note that it's not being used to make an opposite case - I'd said at the
time pausing didn't make sense in a patch-cable model, and I'm saying the
same now.  (Also note - my background is more studio engineering and
musician than DSP expertise, which is probably why the 1/4" cable model
makes sense to me.)  Note that we DID pause playback on disconnected
subgraphs (we may still, I haven't checked), because of the pull-based
implementation we made - I just think it's an unnatural model.

On the gaming audio model - the Gradient Studios guys hit this, and wrote
an HTML5Rocks article about their experience (they had been using
disconnection to pause, and I mentioned that according to Chris this was a
bug, so they rewrote).  I still think if we think connections should be a
pausable thing, we should be able to pause() nodes - but it doesn't make
sense for all types of nodes (cf the audio input case).  I could foresee
wanting a pause() on AudioBufferSourceNode, but I don't think the general
pattern is great, because I'll end up disconnecting graphs just to pause
them.

On the other hand, it is at least possible to "pause"
> AudioBufferSourceNodes in a general sense, so I can't complain that pausing
> is impossible for my use cases. But it does seem like it comes up a lot, so
> maybe it should be supported in a formal manner instead of through 'back
> doors' like it being a side effect of graph disconnection... I assume the
> reason it is undesirable is that it eliminates the simplicity of having a
> single global currentTime.
>

That, and I think it's weird to have pausing, if it's globally desirable,
to only be supported as a side effect.

-Chris