Thank you for your answer.
afaict, you misunderstood the idea.
Honestly, I was thinking simply to another idea. The point is to write with a [readsf~] into a table and then read the table with a [phasor~]. In this way one can simulate the [soundfiler], that is probably the first Miller's suggestion. Anyway, apart write the chunk-reader method, this can be done using a time-counter and a [switch~] in an [until] loop, in a blocking way, or writing a delay line and reading it, that is non-blocking. In this case, one has generally to accept the delay.
Best, Marco
2018-03-06 18:35 GMT+01:00 IOhannes m zmölnig zmoelnig@iem.at:
On 03/06/2018 03:25 PM, Marco Matteo Markidis wrote:
I think the problem in reading soundfile from hard disk is to access to
it,
obviously.
so reducing the accesses to hard disk can be a good practice to reduce audio interruption.
not necessarily. there is an operating system between Pd and the harddisk that does all kinds of caching and what not. also, if you have a spinning harddrive (as opposed to SSD) you will have much better performance if the disk keeps spinning (e.g. by polling it often).
the idea to write in a table and then read it outside the up-sampled
canvas
sounds great, however it is not clear how to read chunks without every
time
close the file descriptor. could be an idea to add a method for read
chunks
without close the fd? or there is an alternative way without write code?
afaict, you misunderstood the idea.
actually [readsf~] is quite good when it comes to reading soundfiles without blocking. the soundfile reading happends in a separate thread (so the main/audio thread will not be blocked) and you can specify a buffer time to give it enough time to seek the file.
but if you have a high bandwidth signal (e.g. a heavy multitrack recording) and the disk is just too slow to serve that data, then you can open and close file descriptors and juggle with blocks-to-read as you will, without being able to solve the problem.
so if tweaking the buffer size doesn't give you click-free play back, i doubt whether *anything* will help, short of getting a faster harddisk (RAMdisk, SSD, nvram).
gfdstr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list