[PD] readsf re-blocked up-sampled

Marco Matteo Markidis mm.markidis at gmail.com
Thu Mar 8 21:50:21 CET 2018


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 at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list
>
>


-- 
Ho cambiato l'indirizzo email in mm.markidis at autistici.org . Se non è un
problema, scrivimi a questo nuovo indirizzo email.

I changed my email address in mm.markidis at autistici.org . If it is ok for
you, please write me to this new email address.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180308/d115fdf4/attachment-0001.html>


More information about the Pd-list mailing list