Issue metadata
Sign in to add a comment
|
Looping AudioBufferSourceNodes leak if disconnected immediately after stop()
Reported by
andrew.macpherson@soundtrap.com,
Mar 22 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36 Steps to reproduce the problem: 1. Build Chromium with DEBUG_AUDIONODE_REFERENCES enabled in AudioNode.h 2. Load this fiddle: https://jsfiddle.net/o7rfhbnb/1/ 3. See the number of outstanding AudioBufferSourceNodes climbing even though they have no visible references, forcing GC in DevTools has no effect What is the expected behavior? Garbage collection should remove these nodes. Changing the fiddle to use non-looping ones appears to behave as expected (once there are >20 nodes, for some reason). What went wrong? These AudioBufferSourceNodes seem to never be garbage collected, resulting constantly increasing memory use. Did this work before? N/A Chrome version: 59.0.3047.0 Channel: canary OS Version: OS X 10.12.3 Flash Version: I'm not sure if this is a bug or just a misunderstanding of the behavior but it feels like a bug since these stop/disconnect calls seem like the natural way to remove a node that's no longer required.
,
Mar 23 2017
You create source nodes that are connected to the destination, and set looping to true, and you've started them. And then drop the JS reference to the node. This is working as intended. The spec says that nodes must continue to play audio even if the JS reference is dropped. And because loop is true, the node can never stop of it's own accord because it's looping forever. This is part of the fire-and-forget approach taken by WebAudio.
,
Mar 23 2017
Oh, wait. I missed the call to stop. That should stop the node and enable the node to be collected. More investigation needed....
,
Mar 23 2017
One issue is last.disconnect(). You've disconnected the node from the destination which means it will never get pulled again, which means any internal processing will not happen. Because of this, the processing loop that would handle the call to stop(0) to stop the node and mark it as finished never gets called either. So the node leaks.
,
Mar 28 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 27
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by kochi@chromium.org
, Mar 22 2017Status: Untriaged (was: Unconfirmed)