[PD] help making sense of [readsf~]

[Christof Ressi]

Actually, I forgot something important:

Of course, the worker thread must also *open* the file! If the file is 
not yet cached by the OS, this can indeed take a few milliseconds.If you 
don't add some delay between "open" and "start", you might notice that 
you get a dropout the very first time, but not on subsequent times.

In fact, if you don't wait between "open" and "start", the perform 
method almost certainly blocks. However, often we don't notice because 
it may be "absorbed" by Pd's own ringbuffer (= "Delay" in the audio 
settings).

Anyway, I agree that the help needs some more clarification! (Just make 
sure you really understand how the object works before changing the help 
patch :)

  Christof

On 04.03.2024 06:23, Christof Ressi wrote:
> 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
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20240304/5c89927e/attachment.htm>