Some sort of `dispose` method about opus-recorder HOT 5 CLOSED

Can you be more specific about this memory leak? In what scenarios, browsers, and operating systems?
Do you have an example case you can provide?
Since we are storing audio in memory it is expected that memory usage increase as long as you are recording.

from opus-recorder.

Here is simpliest example:

1. open example.html
2. click init. click record. click done. At this step you got record
3. repeat step 2

Each time you do step 2, the new Worker is created. And it's not terminated at (or after) done step.
You can view this in Chrome with dev tools: after this repeats, open tab profiles and there you can choose some workers created by init.

from opus-recorder.

The simpliest way for cleaning memory I found — call recorder.worker.terminate(), where recorder is instance of Recorder. And do this each time you going to create new instance.
But it can be not all, because there are event listeners and more.

from opus-recorder.

I think current flow with init, record, done is not perfect: it would be much better, if record became auto started after init step. So API became simplier and cleaner.

This is how I see it:

1. instantinating Record starts recording and returns controller.
2. Controller has methods for
   • pause/resume
   • reset that starts record over
   • done that finalizes record and makes available getOgg
   • dispose that does things: stops record if it's not stopped, terminates worker and cleans memory of instance

There is another thought — it might be better to not instantinate Worker each time, because this takes time and cpu resources as well. In case of ogg, it has 4 network requests each time (recorderWorker.js, than oggopus.js, than libopus.js and than wavepcm.js.

Audio capture is not in worker and worker does only encoding. So it's consistent and might be saved for next record calls. The only problem that might be here — two separate instances of Recorder doing record in parrallel (don't now if this possible). This way, worker should be rewrited to be stateless and just doing things as they arrives by onmessage.

from opus-recorder.

With commit 962f19f, I aligned somewhat with MediaRecorder https://developer.mozilla.org/en-US/docs/Web/API/MediaRecorder. Worker is now initialized on start and destroyed on stop. Chrome seems to handle caching the scripts alright. I still see the memory increasing, but it does not go down after refreshing the tab so I think it is not related to my lib.

from opus-recorder.