[PD] help making sense of [readsf~]

[Christof Ressi]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20240304/8272a96c/attachment.htm>