[PD] readsf~ questions

Christof Ressi info at christofressi.com
Sat Sep 11 02:53:22 CEST 2021


Here's some more background info:

If [readsf~] notices that the read buffer is empty, it doesn't just 
output silence, instead it signals the I/O thread and waits until data 
is available. This means that the outpout of [readsf~] is always 
deterministic!

Now, if you call [1( right after [open(, the read buffer might still be 
empty on the next call of the perform routine, so [readsf~] can block 
for some time.

I have added some debugging statements in the [readsf~] code to check 
when and how long the perform routine blocks.

First I use 
https://docs.microsoft.com/de-de/sysinternals/downloads/rammap to clear 
the file cache. Then I try to play a soundfile repeatedly without delay 
between [open( and [1(. These are the results:

readsf~: wait...
readsf~: ... done
readsf~ blocked for 5.931837 ms
readsf~: wait...
readsf~: ... done
readsf~ blocked for 0.007390 ms
readsf~: wait...
readsf~: ... done
readsf~ blocked for 0.169551 ms
readsf~: wait...
readsf~: ... done
readsf~ blocked for 0.008211 ms
readsf~: wait...
readsf~: ... done
readsf~ blocked for 0.129729 ms
readsf~: wait...
readsf~: ... done
readsf~ blocked for 0.014779 ms
readsf~: wait...
readsf~: ... done
readsf~ blocked for 0.137119 ms
readsf~: wait...
readsf~: ... done
readsf~ blocked for 0.034896 ms

Initially the file is not cached and Pd blocks for about 6 ms, but 
subsequent reads only block for a fraction of a milliseconds.

But as IOhannes has pointed, this is very dependent on your OS, the size 
of the file and the overall state of the file cache. Often you can get 
away with reopening the file without delay, but it is not 100% safe, so 
you should better add a [delay]. If you want to loop without gaps, you 
can actually use two [readsf~] objects and call [1( and [open( alternately.

---

By the way, the help patch for [readsf~] really needs to be updated. It 
currently says:

> You must open the soundfile in advance (a couple of seconds before 
> you'll need it) using the "open" message.
This should really be "a couple of milliseconds". Also, we could add 
"... otherwise Pd might block" to make clear what happens.

---

As a side note: it would be great if [readsf~] had something like a 
[seek( method, where you can seek to a specific sample onset. It's 
already possible with [open(, but it's a bit cumbersome and it would 
unnecessarily reopen the file.

Note that [seek( could block as well, so we would have to

1) stop playback

2) [seek(

3) start playback after some delay

Also, [readsf~] could have a "non-blocking" mode which would just output 
zeros as long as the buffer is empty - instead of blocking Pd. Playback 
would be undeterministic, but in many scenarios this is not an issue. 
Looping would be as simple as connecting the right outlet of [readsf~] 
to [seek 0(.

Christof


On 10.09.2021 17:18, IOhannes m zmoelnig wrote:
> On 9/10/21 8:37 AM, Simon Iten wrote:
>> hi there,
>>
>> I am finding conflicting (unclear) info on readsf~ behaviour. I want to
>> loop a long 8 channel wave file.
>> here are my questions:
>>
>> -once i open the file with a message and after a delay start playback 
>> and
>> it has finished (rightmost outlet bangs), can i restart playback without
>> delay ([t b b] to open and 1 for start) or do I have to set a delay 
>> again?
>> (will the buffer somehow be ready faster)
>
> that depends on your OS. most likely the file will be cached, so 
> sequential opens should be fast (but this of course depends on how 
> large the file actually is).
>
> a 8-channel soundfile with 15minutes data and 16bit samples will have 
> about 600MB at 44kHz.
> that probably should be OK to cache (but then: do you have other 
> largish datasets that are loaded as well?)
>
>>
>> -if above is not possible, what happens if the open message is sent 15
>> minutes before the 1 message to start playback, are there any downsides?
>> the fact that I can set a buffer size seems to suggest that that buffer
>> will simply be filled and after that it waits for the playback to start. 
>
> that is correct.
> the delay is justa means to give Pd time to fill the buffer.
> once the buffer is filled, Pd will just idle away until it starts 
> depleting.
>
> tg,dsr
> IOhannes
>
>
> _______________________________________________
> 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/20210911/ba3a53ea/attachment.htm>


More information about the Pd-list mailing list