[Bug 17794] Behavior of unconnected nodes needs to be specified

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17794

--- Comment #1 from Chris Rogers <crogers@google.com> 2012-07-30 20:24:44 UTC ---
(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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 30 July 2012 20:24:46 UTC