This is a "feature" of PureData. Some objects are designed in such a way that they perform their task all at once rather than spreading it across a longer time (see e.g.: here for a much deeper insight on the issue). [soundfiler]
is such an object: when you send it a [read(
message, it will go to the disk, read the file, load it in memory. All of this in "zero logical-time", which means: according to Puredata this should happen instantaneously. In practice, though this always takes longer than "zero" time, and as such you get audio dropouts (that is: Puredata is still busy reading the input file when it should instead be preparing the next output samples). While you may occasionally get away with this with very short files, a fast storage and a large and - most importantly - an operating system that is willing to service your disk access immediately, this is very often not the case on Bela.
This is for a combination of all these factors:
1. default blocksize on Bela is 16 samples, while on Pd on a desktop it is 64 samples (though more often than not you will have to add some "Delay (msec)" in Pd's preference panel to make it work at this block size).
2. reading from the SD card is most likely slower than reading from a modern SSD
3. reading a file is intrinsically a non real-time operation, which means that there is no guarantee that you will be done on time (it may work occasionally, but then one day that will bite you!)
4. Bela obtains the high performance and low latency by leveraging Xenomai, a real-time extension that guarantees small and bounded response time. By requesting to access the disk, you are switching out of Xenomai mode into Linux mode (the "mode switch" you are notified about), losing the guarantee of meeting your deadlines. It must be noted that this is not a limitation of Bela: no audio code should ever have to wait for disk or networkI/O (see e.g.: this very informative post), Bela simply enforces you to do so.
As suggested also in the Pd "tips and tricks": how to avoid audio drop-outs, you should not use [soundfiler]
while the patch is running, rather either use it at the very beginning (e.g.: connected to a [loadbang]
), if you have a small number of short files (e.g.: something that will fit in RAM without troubles) to be played back, or use [readsf~]
and [writesf~]
instead.