I consider to buy a bela board for a project. I need to stream very long (hours) WAV files from SD Card. I need to play 24 files simultaneously. I read in the forum that 12 tracks should be fine. But what is the maximum data rate the SD Card Reader can handle? Any experience? Any other supported file formats that work with a combination of soundfiler and readfs~ in pd? I could also use SuperCollider or C++, but this would not change the hardware limits. Any hints are very welcome...
Maximum number of parallel WAV Tracks streaming from SD Card
Interesting subject! I don't know the details but, depending on how the files have to be managed during the streaming, you could also consider pre-conditioning them.
For example, in the trivial case where they just have to play together in fixed relative levels, they could all be pre-mixed in one file (just an extreme example, I guess this is not the case).
If they have to play in variable levels but within limits (e.g. with individual volume but always 24 together), they could have pre-reduced bit depth (e.g. 8 files together won't have more than 1/8 max level, so they could be 3 bits less).
All trivial examples but pre-processing could add on top of max streaming performances.
- Edited
I did a quick test here with a 5 year old class 10 SD card: I can easily stream 35 16-bit WAV files from disk without issues using [readsf~]. I start getting some dropouts at 40 files, but that may be due to my OS being an experimental version, which with Pd adds a bit of overhead due to excessive system logging.
I would expect multichannel fils to perform better than mono files, because the reads are interleaved and there are fewer threads at play (it's one thread per file) so if you are playing stereo files or multiple files that are playing synced all the time, it's best to encode them in a single multi-channel file wherever possible.
The patch I created for this test is here: https://github.com/giuliomoro/pd-play-many-files
It uses dynamic patching to programmatically create a number of instances if the mo.pd mono file player patch which uses [readsf~]. As you notice, there is a gap between the [open ( and [start( commands to [readsf~]. This is expected (see [readsf~]'s help file), because when you [open( a file it starts loading it from disk in a separate thread and it needs a few milliseconds (depending on system load) before it is ready to [start( playing it. That's not an issue if you
If instead you want a lot of files to be ready to play in an arbitrary number without notice and they won't fit in RAM, you can use this trick to preload the initial portion of the file in ram and have the rest played from disk via [readsf~]: https://github.com/giuliomoro/dynamic-load-files-Pd
Note before starting any test you'll want to run sync && echo 3 > /proc/sys/vm/drop_caches so that any files currently cached in RAM doesn't affect the test's result.
I already thought about pre-conditioning the files, but there are too many possible combinations. In my case the effort for rendering all the combinations of hour long tracks in the DAW is simply to high. Still, I am thinking about some trade off: since I am only controlling the volume in groups of four (beside on and off for each channel), I could prepare combinations of 2 channels (12 pairs). This, way the maximum number of files per group which need to be played back individually is 2. This way, I could half the maximum number of channels while keeping the rendering effort realistic (12 extra renders).
I also like your idea of alternating the bit depth, but this would be a bit of over engineering in my case : )
Wow, thank you so much for you quick reply and the provided examples/test results . This sounds very promising, I definitively will give it a try!