[PD] help making sense of [readsf~]

[Alexandre Torres Porres]

Em seg., 4 de mar. de 2024 às 02:25, Christof Ressi <info at christofressi.com>
escreveu:

> A worker thread is reading data from the given file and fills a buffer.


and this buffer size is set via the 2nd argument, right?


> If the buffer is full, it waits until there is space. The thread starts
> to do its job right after the [open( message.
>

And it'll have space when it starts playing, which frees the data from the
buffer, huh?


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

But it's not like we need for the whole buffer to get filled before
playing, right? So we can read and free from the buffer while it's being
filled.


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

I see.


> (BTW, I have no idea why the help patch uses a buffer size of 1 MB...)
>

seems weird in fact to require anything bigger than this, really, and this
should be clear in the help file! When should one care and feel like 65536
isn't enough?


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

maybe worth mentioning.


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

Thing is, I don't think I've ever noticed a dropout and have been ignoring
this warning and playing files right away forever, since I started using Pd
in the 2000s... I got this rather old 2013 macbook air, and using it with a
delay of only 5ms doesn't give me any noticeable dropout!

Can others test this?

This is why I was assuming that it was a concern for pretty old computers.
I thought maybe it was a cpu issue, but I see it could also be hard drive
related now. This ver old macbook air has got SSDs anyway...

> 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 :)
>
that's what I am doing :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20240306/02df84bd/attachment.htm>