To echo Christof, each object has a parallel worker thread as the file I/O could block Pd's audio thread. It takes time to read the beginning of the file (or from the start point) before it can be played back.
IMO the warning / concern in the help file is really from a time of *much* slower media where the file I/O would take a lot longer, especially if a spinning hard drive has to access multiple files in multiple physical locations. Nowadays, speed and (pre-)caching make access times so much faster we don't necessarily think about it except for very large files we need to be able to randomly access.
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. I have never personally needed to use anything but the default readsf~ buffer size.
On Mar 4, 2024, at 12:00 PM, pd-list-request@lists.iem.at wrote:
Message: 2 Date: Mon, 4 Mar 2024 06:23:16 +0100 From: Christof Ressi <info@christofressi.com mailto:info@christofressi.com> To: pd-list@lists.iem.at mailto:pd-list@lists.iem.at Subject: Re: [PD] help making sense of [readsf~] Message-ID: <93bd5dc6-baa9-4097-ac07-ae7683b75479@christofressi.com mailto:93bd5dc6-baa9-4097-ac07-ae7683b75479@christofressi.com> Content-Type: text/plain; charset=UTF-8; format=flowed
Hi,
making it seem it would load the file into an internal memory and not just read directly from the disk
The help file says "soundfile playback from disk"...
Here's how the object works:
A worker thread is reading data from the given file and fills a buffer. If the buffer is full, it waits until there is space. The thread starts to do its job right after the [open( message.
Once we send the [start( message, the perform method simply tries to read a block of samples from the buffer and copy it to the outlets. If there is not enough data in the buffer, the method blocks - which is something we definitely want to avoid! This is exactly the reason why we need to wait a little bit between the [open( message and the [start( message; otherwise the perform routine might have to wait for the buffer, causing a dropout.
The second argument for [readsf~] is the size of the buffer. The default value seems to be 262144 bytes (per channel). In single-precision Pd that corresponds to 65536 samples, which should be more than enough. I think this value comes from the times where everybody had slow HDDs with unpredictable seek times; for modern SSDs it can be much smaller, but we probably don't care about a few kilobytes.
(BTW, I have no idea why the help patch uses a buffer size of 1 MB...)
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
-
Christof Ressi -
Dan Wilcox