You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I’m always frustrated when using the recorder library with streams because the library automatically stores recorded audio data in the browser’s memory. This leads to high memory usage during long recording sessions, especially in browser environments where memory is limited. There is currently no way to disable this storage when working with streams, which causes performance issues and potential crashes for applications with extended audio recording functionality.
Describe the solution you'd like
I would like the library to implement a feature that allows disabling the automatic storage of audio data in the browser’s memory when using streams. For example, an option in the configuration like disableMemoryStorage: true would be ideal. When this option is enabled, the library should handle the stream as a pass-through, processing chunks in real-time without keeping them in memory.
Describe alternatives you've considered
As a workaround, I have tried manually clearing memory after recording by intercepting and processing the audio data, but this is cumbersome and does not fully solve the problem since the library continues to allocate memory during recording. Additionally, I considered switching to other libraries, but recorder provides unique features that are difficult to replicate elsewhere.
Additional context
Here is a snapshot from the browser’s memory analysis showing how JSArrayBufferData grows significantly during recording:
This issue becomes critical for web applications with real-time audio streaming requirements. Adding the requested feature would make the library much more suitable for such use cases.
The text was updated successfully, but these errors were encountered:
Thanks for reporting, the package does not retain any audio data for long.
If your implementation is nearly equivalent to the example, so yes bytes are stored in memory. But this is just an example.
It's up to you to store it in a blob or forward the stream to a remote endpoint.
I was unable to reproduce any leak here. JSArrayBufferData in your screenshot does not come from the package and is already at this size just by opening a flutter app in debug mode.
Is your feature request related to a problem? Please describe.
I’m always frustrated when using the recorder library with streams because the library automatically stores recorded audio data in the browser’s memory. This leads to high memory usage during long recording sessions, especially in browser environments where memory is limited. There is currently no way to disable this storage when working with streams, which causes performance issues and potential crashes for applications with extended audio recording functionality.
Describe the solution you'd like
I would like the library to implement a feature that allows disabling the automatic storage of audio data in the browser’s memory when using streams. For example, an option in the configuration like disableMemoryStorage: true would be ideal. When this option is enabled, the library should handle the stream as a pass-through, processing chunks in real-time without keeping them in memory.
Describe alternatives you've considered
As a workaround, I have tried manually clearing memory after recording by intercepting and processing the audio data, but this is cumbersome and does not fully solve the problem since the library continues to allocate memory during recording. Additionally, I considered switching to other libraries, but recorder provides unique features that are difficult to replicate elsewhere.
Additional context
Here is a snapshot from the browser’s memory analysis showing how JSArrayBufferData grows significantly during recording:
This issue becomes critical for web applications with real-time audio streaming requirements. Adding the requested feature would make the library much more suitable for such use cases.
The text was updated successfully, but these errors were encountered: