Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Saving file as it is streamed #60

Open
Yahsfa opened this issue Apr 14, 2022 · 3 comments
Open

Saving file as it is streamed #60

Yahsfa opened this issue Apr 14, 2022 · 3 comments

Comments

@Yahsfa
Copy link

Yahsfa commented Apr 14, 2022

I am working on a project in which data keeps streaming in and I need to save the frames to wav as they come in. I cannot wait until I have all the data to save and the sequence load_wav-add_samplesa-save_wav seems wasteful and I may lose frames.
Is there a better way to "flush" the frames to disk without having to close the file all the time?

@adamstark
Copy link
Owner

Hi there, this is a nice idea but I don't know how I would generate meaning full header data (number of samples, etc) if all that could change in real-time. Is there a reason you can't stream to a vector of vectors and then save it to the audio file when needed? At the point of saving, the number of samples and other header data is known.

@Yahsfa
Copy link
Author

Yahsfa commented Aug 1, 2022

The problem is that the streaming can go on for a long while which might make it not practical in terms of memory usage. Plus it is possible that the application terminates relatively suddenly where not having the last few frames might not be too bad but losing everything would be a big deal.

@adamstark
Copy link
Owner

adamstark commented Aug 1, 2022

I definitely understand the use-case. I think it is best handled outside of this library though - I intended this library as a tool for reading/writing audio files. I can see a useful AudioBuffer library doing some of what you refer to also - but lots of this depends on the application in question. E.g. if we are streaming audio on the audio thread, we shouldn't be allocating memory to do so (we should pre-allocate enough for our needs, or do something else with thread management). It's impossible for the AudioFile library to know if it is being used in this way, which is why it is best handled at the application level rather than in this library I think :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants