[PD] help making sense of [readsf~]

[Christof Ressi]

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...)

---

[writesf~] behaves just the otherway round. Since the perform routine is 
the producer, we don't need to wait after the [open( message. But after 
we send [stop(, we should to wait for the worker thread to drain the 
buffer and write the data to disk before we send another [open( message.

Christof

On 04.03.2024 05:24, Alexandre Torres Porres wrote:
> Hi, a discussion on facebook led me to revise the help file of 
> [readsf~] and I'm making some edits and changes. It seems it wasn't 
> all to clear how it works, making it seem it would load the file into 
> an internal memory and not just read directly from the disk, and in 
> fact I'm not really sure how it works.
>
> Also, the help has been saying forever how one should open a file "a 
> bit" in advance, which is vague and it also doesn't make it clear why 
> and how long soon... it also says it starts reading from the file 
> right away, but doesn't play it until you say so... this is what makes 
> it a bit confusing to people I guess, cause it seems to load into 
> memory. Now, I believe there is some operation that is done in advance 
> and then it adds some latency maybe, so if you do it in advance you 
> get to manage this a bit better, is that it?
>
> Can we have and add a bit more information about it?
>
> Also, is it the case that this used to be a somewhat significant issue 
> back in the day, which means this has become not significant all for a 
> while?
>
> Last, but not least, I can't make much sense of the 2nd argument. I 
> had a look at the code to see what is the default value (which is also 
> the minimum allowed value), something I always put on the help files, 
> and I wonder if this is some kind of memory buffer that we load the 
> file into... Moreover, why would someone need a bigger buffer than the 
> default value?
>
> I need this information well sorted to make this help file as nice as 
> the others.
>
> Cheers!
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list