Every call to wavesurferjs keeps on increasing RAM memory, without releasing it on destroy.

I have came across a issue with wavesurferjs it does not release memory previously held upon destroy.

With high duration audio file, if we open 10 times it will hang browser itself (then we need to either hard refresh or close browser itself to continue).

Steps to reproduce on linux:

1.open terminal type $htop 2.keep on opening audio with destroy on closing. 3.memory will keep on adding

Though i’m not a good programmer, but i have found a exact solution with canvas and audio api

Here is that solution: https://stackoverflow.com/questions/53241345/web-audio-api-memory-leak?noredirect=1&lq=1

i request @katspaugh , please implement it as soon as possible.

[a2-rmiller]

AudioBuffer did not decrease in size and references to the buffers was being kept around even after all instances were destroyed after testing using multiple heap snapshots in Chrome.

On my end, I resolved this (before doing anything) by straight up deleting the buffer first.

delete this.wave.backend.buffer;

After the buffer is deleted, I run my regular destroying things like this.wave.destroy(); etc.

This solves the memory leak for me, which was upwards of 400mb every instantiation of a new object (using any of the recoemmdned backends).

[marcelblum]

Hello, I’ve been noticing this same issue on my end (Win 10, latest Chrome, latest Wavesurfer). I can confirm that Wavesurfer is erroneously not releasing the audio buffer after a call to destroy(), which results in the buffer not being garbage collected and persisting in memory even after subsequent calls to load() different sound files using the same Wavesurfer instance. This is most apparent when using large audio files. I know those MDN docs recommend short sound files but in practice on a decent machine Chrome handles larger audio files beautifully and I often work with tracks >1 hour in length as decoded buffers with the Web Audio API with no issues. If you set a variable holding an audio buffer to null the memory is typically purged within seconds by the garbage collector. Therefore this is almost certainly not a Web Audio API/browser bug. Wavesurfer handles drawing large sounds beautifully too, but even after a call to destroy I can see that there are still retained references to the buffer in the Wavesurfer object, preventing garbage collection. Simple example, go to https://wavesurfer-js.org/ and open the console:

wavesurfer.destroy();
console.log(wavesurfer.backend.source.buffer);
//->AudioBuffer {length: 1045146, duration: 21.773875, sampleRate: 48000, numberOfChannels: 1}
//buffer is still assigned to a variable and can't be garbage collected!
wavesurfer.backend.destroy();
console.log(wavesurfer.backend.source.buffer);
//->AudioBuffer {length: 1045146, duration: 21.773875, sampleRate: 48000, numberOfChannels: 1}
//even now buffer is still referenced in the wavesurfer object!

However even if I try manually wavesurfer.backend.source.buffer = null the buffer is still not garbage collected so I suspect there remains some reference to it even elsewhere in the Wavesurfer code that I haven’t figured out yet, perhaps you have an idea?

And just as a demonstration here is simple vanilla Web Audio API code that loads a large audio file and then purges it when done, easily observable in Windows Task Manager:

var audioCtx = new AudioContext();
var buffer;
var request = new XMLHttpRequest();
request.open("GET", "https://soundplant.org/fruits/Christian%20Wolff%20-%20Edges%20-%20Gentle%20Fire.mp3");
request.responseType = "arraybuffer";
request.onload = function() {
    console.log("loaded");
    let undecodedAudio = request.response;
    audioCtx.decodeAudioData(undecodedAudio, (data) => {
        console.log("decoded");
        buffer = data;
    });
};
request.send();
/* Chrome loads ~300mb audio data into memory observable in Task Manager */
buffer = null;
request = null;
/* usually within a few seconds, 300mb purged from Chrome's used memory observable in Task Manager */