WaveSurfer stops working after several destroy() calls

[guillermo-empathy]

Issue

I'm facing performance issues when using wavesurfer.js with the RecordPlugin in my application based in Ionic/Angular when run on Android.

I'm dynamically creating and destroying multiple WaveSurfer instances over the same container to handle different audio files generated by the RecordPlugin. Each time I finish a recording, the component is destroyed and tested that ngOnDestroy is triggered. However, after creating and destroying several instances I've noticed a significant performance degradation, and after the 10th created instance WaveSurfer stops working.

Reproduce the issue

A simplified Angular-based project demonstrating the issue is available at https://stackblitz.com/edit/stackblitz-starters-8ijgtr?file=src%2Fapp%2Fwave%2Fwave.component.ts. To reproduce the error, follow these steps on a mobile browser, Android preferred:

1. Start recording.
2. Pause recording.
3. Play the recording.
4. End recording.

Repeat this sequence approximately 10 times. The Wavesurfer instance should fail to function after the tenth iteration.

Potential Causes

• Memory leaks related to my Wavesurfer or RecordPlugin usage.
• Inefficient resource management on Android devices.
• Conflicts between Ionic/Angular and Wavesurfer.
• Underlying issues with the Web Audio API on Android.

I'm seeking guidance on:

• Identifying the root cause of the performance degradation and instability.
• Optimizing Wavesurfer usage within a dynamic component environment.
• Effectively managing resources and preventing memory leaks.
• Troubleshooting the specific error conditions that lead to Wavesurfer failure.
• Any insights or suggestions from the Wavesurfer community would be greatly appreciated.

Additional Information

I can provide more detailed code snippets and information if its needed.

[katspaugh]

This is most likely a Web Audio memory leak. You can use Chrome's devtools (the Memory tab) to see where the decoded buffer is trapped.

I doubt it's a JS leak, but briefly checking the code, I see that this.audioData is never nullified in renderer.ts on destroy, so it might help to do that. However, if your outer code properly disposes of the entire wavesurfer instance reference on destroy, it shouldn't matter.

[guillermo-empathy]

Thanks for your answer. I have made a fork of the repository to nullify the this.audioData on destroy, but testing it seems to have no effect on this issue

[guillermo-empathy]

I replicated the issue on an HTML+JS only project based on the official example for the RecordPlugin. Same problem as before, after recording several times on mobile browser the recorded audio won't play and waves stop working: https://stackblitz.com/edit/vitejs-vite-uzxtct?file=main.js

[katspaugh]

Do I get it right that this problem is specific to the Record plugin and not just wavesurfer alone?

[guillermo-empathy]

Yes, it seems to be specific to the Record plugin because in this other test project I have made that every time the Play button is pressed it destroys the wavesurfer instance and initializes it again (without RecordPlugin), and it never breaks https://stackblitz.com/edit/vitejs-vite-lh3cyb?file=main.js

[katspaugh]

OK. That’s good. Next step would be to isolate where in the Record plugin the memory is trapped. Maybe one of the browser APIs isn’t disconnected/destroyed properly.

[guillermo-empathy]

It seems that in mobile browser the MediaStream and AudioContext objects are not released from memory after they are stopped/destroyed. This problem does not occur with desktop browsers.

[katspaugh]

Looking at the code and the docs, mediaRecorder.stop() seems to be the only thing we can do with it on destroy. So it's probably a browser bug. Audio context is also stopped properly (audioContext.close) so it should release the memory.

As a workaround, you could try re-using the same AudioContext and MediaRecorder objects across wavesurfer instances maybe? I.e. cache them somewhere in an outer scope that persists after a destroy.