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? > 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 :)
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
