[PD] readsf re-blocked up-sampled

IOhannes m zmölnig zmoelnig at iem.at
Tue Mar 6 18:35:42 CET 2018


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180306/6ab1ab85/attachment.sig>


More information about the Pd-list mailing list