17794 2012-07-17 18:34:19 +0000 Behavior of unconnected nodes needs to be specified 2014-10-28 17:17:01 +0000 1 1 1 Unclassified AudioWG Web Audio API unspecified All Windows 3.1 CLOSED WONTFIX P2 normal TBD 1 cwilso crogers public-audio oldest_to_newest 70049 0 cwilso 2012-07-17 18:34:19 +0000 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. 71670 1 crogers 2012-07-30 20:24:44 +0000 (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. 113892 2 olivier.thereaux 2014-10-28 17:14:09 +0000 Web Audio API issues have been migrated to Github. See https://github.com/WebAudio/web-audio-api/issues 114038 3 olivier.thereaux 2014-10-28 17:17:01 +0000 Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.