As Christof says, fine tuning the reader buffer size could be thought of as fine tuning the audio buffer length, ie. a 64 block size is faster but has less space/time if your patch does some really CPU intensive stuff. If you don't need super responsively, you can increase the block size.

Just to clarify: the buffer for readsf~ itself does not cause any delay, so larger values don't hurt (except for wasting some kilobytes). The latency is explicitly controlled by the user as the time between the "open" and "start" message.

(The reason why the buffer itself does not cause a delay is because the worker thread is "eager", i.e. it already has all the data available and so it always fills the buffer as fast as possible. This is different to an audio device where the audio input is produced at the same rate as it is consumed.)

I have never personally needed to use anything but the default readsf~ buffer size.
Yes, as I noted, the default buffer size is 65356 samples, which is over 1 second of audio at 48 kHz. This is much more than we will ever need on modern systems. The user only needs to think about the wait time between "open" and "start" to avoid *initial* dropouts.

Christof
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to