afaict, you misunderstood the idea.
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/listinfo/pd-list