Creating ~50 nodes via .getNode() yields "RangeError: WebAssembly.Instance(): Out of memory: wasm memory"

[grame-cncm]

Creating ~50 nodes via .getNode() yields "RangeError: WebAssembly.Instance(): Out of memory: wasm memory"

[dxinteractive]

Further research makes it seems like this might be just how memory allocation behaves with WebAssembly. I don't know enough to say definitively though. I can make Faust IDE stop working with the same error by compiling a patch ~50 times, or compiling ~50 different patches.

[dxinteractive]

Silly hack that circumvents the issue: put all the faust audio compilation stuff in a newly-created iframe, and remove the iframe and recreate the iframe after every compile. When the iframe is gone, it seems the resources attached to that iframe are gone too, or at the very least you get a new memory pool to use when the new iframe is loaded. I'm sure this is potentially unsuitable for many reasons, but I'm going to see how far I can take this idea 😂

How I got here: I'm making a web app that renders audio in an OfflineAudioContext, and most nodes are dynamically compiled Faust AudioWorkletNodes (although not using this library). I'm using a mix of mainly Faust, and a few other nodes to do things that Faust can't do like web audio's native convolution node, which is why I'm interested in OfflineAudioContexts in the first place. But after ~50 offline renders I have been hitting the same limitations as described above. It's much easier to hit this limit with offline rendering because OfflineAudioContexts can't be reused, and new audio nodes need to be created for every new render, even if they are functionally identical, which I find to be an awkward situation. And creating all those new nodes leads to the "out of memory" error I described above. I then searched to see if anyone else hit this issue, found this library, but then realised the issue still exists here too.