Pre-loading background noise (and IR) in __init__?
See original GitHub issueIf one of the objective of torch-audiomentations
is to do fast augmentation on GPU as part of a larger network, reading from disk for each new audio sample would slow down the forward pass dramatically, wouldn’t it?
Would it make sense to allow the user to preload the whole background noise collection in memory during __init__
and then read from memory in apply_transform
?
Or, if the background noise collection is too big to fit in memory, we could load a bunch of them, use them for a while, and then load another (random) bunch of them, etc.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:2
- Comments:5 (2 by maintainers)
Top Results From Across the Web
How To Create A Custom Preloading Screen | CSS3 Tutorial
Learn how to create a custom CSS3 animated preloading screen. Use CSS3 transitions and CSS3 animations to create an elegant preloading screen effect....
Read more >Load in Background - Optimizing Audio Load Times in Unity
Selecting both Preload Audio Data and Load in Background means the audio data will begin loading during the scene loading process, but the ......
Read more >Create a Quick MooTools Slideshow with Preloading Images
The following code snippet will show you how to create a simple slideshow with MooTools; the script will also preload the images and...
Read more >How to Create an Awesome Image Preloader - Code
To fix the problem mentioned above, we'll load the icon first, and then call the init function. But the loading icon is a...
Read more >High Fidelity, Near-Field Two-Way Audio Reference With ...
also capture ambient noise in addition to the useful near-end audio signal. The captured multi-microphone audio signals are corrupted by acoustic background.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I usually have 64GB or more of RAM but quite slow I/O, so yes, it makes complete sense.
This is more complicated, because you don’t know what the user can afford etc… But still doable. But the first option is definitely possible and a
preload_wavs
flag or something like that could completely do the job.Yes. Big RAM, slow I/O as well, here 😃