[PD] help making sense of [readsf~]

[Christof Ressi]

On 07.03.2024 01:27, Alexandre Torres Porres wrote:
> 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?
Yes!
>
>     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?
Yes, although "frees the data" is the wrong term. The perform routine 
reads a range of samples and advances the read pointer, after which 
these samples can be *overwritten* by the worker thread. It's just a 
simple ringbuffer.
>
>     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.
Yes! Although in practice the buffer will be filled pretty quickly once 
the soundfile has been opened. One could say that the perform routine 
"drives" the worker thread.
>
>     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?
Pretty much never.
>
>     [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!
I did and still do notice it! Opening a file (that is not cached by the 
OS) can take a few milliseconds. If your delay setting is low and CPU 
load is high, you can easily get a 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 :)
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20240307/4bcd901f/attachment.htm>