<div dir="ltr">Thank you for your answer. <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.800000190734863px">afaict, you misunderstood the idea.</span></blockquote><div>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.</div><div><br></div><div>Best,</div><div>Marco</div><div class="gmail_extra"><br><div class="gmail_quote">2018-03-06 18:35 GMT+01:00 IOhannes m zmölnig <span dir="ltr"><<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 03/06/2018 03:25 PM, Marco Matteo Markidis wrote:<br>
> I think the problem in reading soundfile from hard disk is to access to it,<br>
<br>
</span>obviously.<br>
<span><br>
> so reducing the accesses to hard disk can be a good practice to reduce<br>
> audio interruption.<br>
<br>
</span>not necessarily.<br>
there is an operating system between Pd and the harddisk that does all<br>
kinds of caching and what not.<br>
also, if you have a spinning harddrive (as opposed to SSD) you will have<br>
much better performance if the disk keeps spinning (e.g. by polling it<br>
often).<br>
<span><br>
><br>
> the idea to write in a table and then read it outside the up-sampled canvas<br>
> sounds great, however it is not clear how to read chunks without every time<br>
> close the file descriptor. could be an idea to add a method for read chunks<br>
> without close the fd? or there is an alternative way without write code?<br>
<br>
</span>afaict, you misunderstood the idea.<br>
<br>
actually [readsf~] is quite good when it comes to reading soundfiles<br>
without blocking. the soundfile reading happends in a separate thread<br>
(so the main/audio thread will not be blocked) and you can specify a<br>
buffer time to give it enough time to seek the file.<br>
<br>
but if you have a high bandwidth signal (e.g. a heavy multitrack<br>
recording) and the disk is just too slow to serve that data, then you<br>
can open and close file descriptors and juggle with blocks-to-read as<br>
you will, without being able to solve the problem.<br>
<br>
so if tweaking the buffer size doesn't give you click-free play back, i<br>
doubt whether *anything* will help, short of getting a faster harddisk<br>
(RAMdisk, SSD, nvram).<br>
<br>
gfdstr<br>
<span class="m_-4498432675451862761HOEnZb"><font color="#888888">IOhannes<br>
<br>
</font></span><br>______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/li<wbr>stinfo/pd-list</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-4498432675451862761gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Ho cambiato l'indirizzo email in <a href="mailto:mm.markidis@autistici.org" target="_blank">mm.markidis@autistici.org</a> . Se non è un problema, scrivimi a questo nuovo indirizzo email.<div><br></div><div>I changed my email address in <a href="mailto:mm.markidis@autistici.org" target="_blank">mm.markidis@autistici.org</a> . If it is ok for you, please write me to this new email address.</div></div></div>
</div></div>