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.
