IOS WebAudioPlugin Memory Leak

[andrewmunro]

Hey, I'm finding a memory leak when using the web audio plugin on all IOS devices. After adding and removing 8 or 9 sounds, the safari browser will crash as it runs out of memory.

After switching to use the html audio plugin, this is no longer a problem as it correctly removes sounds from memory, however it breaks support for IOS6 and Ipad 3 devices. This makes me believe that the problem lies within the web audio plugin, and not my usage of it. This occurs on the current version, which I compiled myself yesterday from the repo.

My setup is very complex, using haxe compiled to JS to load and unload sounds, so I will get to work on a basic web application to reproduce it with the same sounds. Any help or knowledge on this would be appreciated as I am unable to find any solutions online.

Thanks

[andrewmunro]

Ok, I have successfully reproduced this issue in a simple page. You can find it here:

http://files.dubitlimited.com/sjstest

It's best to test on the Ipad 2 because it has a lower memory limit, it crashes around 26 replays.

Looking in the chrome inspector running on pc, there seems to be no issues with the memory. I wonder if it's a mobile safari related issue..

[andrewmunro]

I have also found that preloading of audio on Ipad 3 IOS 7 does not work with the html audio plugin, yet your documentation only mentions this limitation for IOS 6 devices. Are you aware of this?

[OJayRobinson]

Hi Andrew thanks for reporting this issue.
You can review a discussion of soundjs memory leaks here and see where its at. It sounds like you already have SoundJS NEXT version from github which gives you all the latest improvements that might help.

Unfortunately I will not have time to investigate this further for awhile, and in my experiments I was finding browser implementation seemed to be causing issues.

[andrewmunro]

@OJayRobinson I have successfully found a fix for this issue, and it's a hacky one 👍

So after some experimentation , I discovered this bug is due to mobile safari, not soundjs. Whilst disabling sounds on ipad for our webapp (to prevent memory leaks and the eventual crash), I accidentally discovered that sounds created in an iframe were being correctly cleaned up.

The solution is simple, whenever a sound is played, create it in a script within an iframe. When you are done, destroy that iframe. I changed my old test to confirm this (the old one crashed at 34 plays):

http://files.dubitlimited.com/sjsiframetest/

[OJayRobinson]

Related issue in the latest version of Chrome:
http://stackoverflow.com/questions/28400437/leaving-a-webpage-with-soundjs-causes-google-chrome-to-crash

[konistehrad]

Dunno if y'all are still tracking this, but we ran up against this pretty hard for our latest project (we don't use SoundJS, but it seems relevant). It seems that simply disconnecting and dereferencing the AudioBufferSourceNode object on iOS Safari isn't enough; you need to manually clear out the reference to its buffer, or the buffer itself leaks. (This implies the AudioBufferSourceNode obj itself leaks, but we didn't see this as a practical limit in our project.)

Unfortunately to do this, a 1-sample long scratch buffer needs to get created, as assigning to null will cause an exception. The statement must be try-catch wrapped, too, as Chrome/FF will throw when .buffer is reassigned at any time.

The solution that worked was:

var ctx = new AudioContext(),
    scratchBuffer = ctx.createBuffer(1, 1, 22050);

class WebAudioAdapter extends AudioAdapter {
    close() {
        if( this.__src ) {
            this.__src.onended = null;
            this.__src.disconnect(0);
            try { this.__src.buffer = scratchBuffer; } catch(e) {}
            this.__src = null;
        }
    }
}

Hope this helps y'all too!

[lannymcnie]

Appreciate you sharing your solution. Feel free to implement in the Github source, and submit a pull request. Otherwise, we will definitely look at implementing

[konistehrad]

I took at stab at this, but I'm not familiar at all with SoundJS's organization. Near as I can tell, the scratch buffer itself should go into WebAudioPlugin.js, be generated in _generateCapabilities, used in playEmptySound then assigned into an instance of WebAudioSoundInstance.js and used during _cleanUpAudioNode. How's that sound?