Re: [web-audio-api] Behavior of unconnected nodes needs to be specified (#8)

> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17794#0) by Chris Rogers on W3C Bugzilla. Mon, 30 Jul 2012 20:24:44 GMT

(In reply to comment #0)
> This can be described as "What happens when a playing node is temporarily
> disconnected?" - or, conversely, "If you play a node, and no one is listening
> (aka connected), does it really play?".
> 
> This first came to my attention when I was working with Z Goddard on the
> Fieldrunners article for HTML5Rocks
> (http://www.html5rocks.com/en/tutorials/webaudio/fieldrunners/) - particularly,
> read the section entitled Pausing Sounds.  In short - they'd noticed that if
> you disconnected an audio connection, it paused the audio "stream".  I thought
> this seemed pretty wrong - knowing what I knew about how automation on
> AudioParams works - in discussions with Chris Rogers, he confirmed this wasn't
> his expected behavior.
> 
> My mental model of connections as an API user still really wants to be "they're
> just like plugging 1/4" audio cables between hardware units," despite knowing
> that is not the case here; I would expect if a node was playing and I
> disconnected its graph, then replugged it 0.5 sec later, it would be 0.5 sec
> further along - i.e., I would expect the behavior to be the same as if I had
> connected the node to a zero-gain gain node connected to the
> audiocontext.destination.

After some early discussions with Chris, and thinking about this for some time, I think this is right and is intuitive.  We need to add more detail in the spec about the intended behavior here.  I have had some concerns about possible performance issues with lots of nodes being disconnected yet still consuming resources.  But I think that in most use cases the disconnect() call is not even needed or used, so this shouldn't be an issue there.  And in the specific cases where disconnect() is used (modular synths, etc.) we'll just need to make sure developers understand the potential performance impact.

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/8#issuecomment-24244073