First apply diff --git a/content/media/webaudio/test/test_delayNode.html b/content/media/webaudio/test/test_delayNode.html --- a/content/media/webaudio/test/test_delayNode.html +++ b/content/media/webaudio/test/test_delayNode.html @@ -62,7 +62,7 @@ var gTest = { context.createDelay(1); // should not throw // Delay the source stream by 2048 frames - delay.delayTime.value = 2048 / context.sampleRate; + delay.delayTime.value = 0.9; source.start(0); return delay; Then run TEST_PATH=content/media/webaudio/test/ make -C obj mochitest-plain Results: WARNING: Leaking the RDF Service.: file /home/karl/moz/dev/rdf/build/nsRDFModule.cpp, line 165 WARNING: YOU ARE LEAKING THE WORLD (at least one JSRuntime and everything alive inside it, that is) AT JS_ShutDown TIME. FIX THIS! I think this is the same issue as bug 872635 was trying to address, but I don't think anything knows how often DelayNodeEngine::ProduceAudioBlock() needs to be called. I'm not clear why this isn't an issue with non-offline contexts.

Spoke with roc about this. With a non-offline AudioContext, ProduceAudioBlock() should be getting called for as long as the stream is in the graph, even if it has no input or output. For OfflineAudioContext, when rendering is completed, we need to tell each node that has a self reference to drop that. I assume there exists something similar for source nodes and we just need to extend that to include nodes that produce output after their inputs are disconnected.

(In reply to comment #1) > Spoke with roc about this. > > With a non-offline AudioContext, ProduceAudioBlock() should be getting called > for as long as the stream is in the graph, even if it has no input or output. > > For OfflineAudioContext, when rendering is completed, we need to tell each node > that has a self reference to drop that. Yeah, that's right. > I assume there exists something similar for source nodes and we just need to > extend that to include nodes that produce output after their inputs are > disconnected. Actually I think we may have this bug for all self-references. :/

Source node self references are released in AudioContext::Shutdown(). We need to call that when offline rendering has completed, which is done in bug 914030 comment 6. Bug 914033 is another situation where offline AudioContexts are not releasing source self references.

(In reply to Karl Tomlinson (:karlt) from comment #1) > With a non-offline AudioContext, ProduceAudioBlock() should be getting > called for as long as the stream is in the graph, even if it has no input or > output. That's true as long the browser keeps running to expire the delay. If the browser shuts down before the delay expires, then there is a shutdown leak, which appears to be harmless. To reproduce, open testcase, then close browser before the beep sounds at 60s.

Rather than having different hashtables for each kind of node that might want to keep a self reference, this adds a generic means to track all such nodes. The intention is to switch existing playing reference code to use this in bug 914033.

https://tbpl.mozilla.org/?tree=Try&rev=f2720a1add3b https://tbpl.mozilla.org/?tree=Try&rev=f48b8d4e053c

https://hg.mozilla.org/integration/mozilla-inbound/rev/efdd34cc38af https://hg.mozilla.org/integration/mozilla-inbound/rev/81d850fca7b0

https://hg.mozilla.org/mozilla-central/rev/efdd34cc38af https://hg.mozilla.org/mozilla-central/rev/81d850fca7b0

Comment on attachment 805096 [details] [diff] [review] register tail references with the AudioContext so they can be removed when the rendering is complete [Approval Request Comment] Please consider this a request for both patches in this bug. Bug caused by (feature/regressing bug #): webaudio User impact if declined: some uses of OfflineAudioContexts will leak JSRuntimes for the lifetime of the browser/application. Testing completed (on m-c, etc.): on m-c, in testsuite Risk to taking this patch (and alternatives if risky): low, limited to webaudio String or IDL/UUID changes made by this patch: none

https://hg.mozilla.org/releases/mozilla-aurora/rev/f9d9a5720f13 https://hg.mozilla.org/releases/mozilla-aurora/rev/8ee7e9982dc4 https://hg.mozilla.org/releases/mozilla-beta/rev/a077f4134546 https://hg.mozilla.org/releases/mozilla-beta/rev/acee2cb7f507

I landed this follow-up patch on Aurora because you need to call Init() to initialize hashtables there: https://hg.mozilla.org/releases/mozilla-beta/rev/8b54e8872194

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #12) > https://hg.mozilla.org/releases/mozilla-beta/rev/8b54e8872194 Looks good, thanks Ehsan!

The Aurora landings are actually these revisions: https://hg.mozilla.org/releases/mozilla-aurora/rev/2350d1dd1133 https://hg.mozilla.org/releases/mozilla-aurora/rev/c9cd3bec15fe Thanks, Ryan! (Aurora does not need to Init() hashtables, only Beta.)