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 <zmoel...@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 > > -- Ho cambiato l'indirizzo email in mm.marki...@autistici.org . Se non è un problema, scrivimi a questo nuovo indirizzo email. I changed my email address in mm.marki...@autistici.org . If it is ok for you, please write me to this new email address.
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list