On 07.03.2024 01:27, Alexandre Torres Porres wrote:
Em seg., 4 de mar. de 2024 às 02:25, Christof Ressi
<i...@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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
