This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
(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.
Web Audio API issues have been migrated to Github. See https://github.com/WebAudio/web-audio-api/issues
Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.