I think the problem in reading soundfile from hard disk is to access to it, so reducing the accesses to hard disk can be a good practice to reduce audio interruption.
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?
best, marco matteo markidis
2018-03-05 13:00 GMT+01:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2018-03-05 12:01, Marco Matteo Markidis wrote:
In my head the point is: is it usefull to use a [readsf~] in a up-sampled subpatch to avoid audio dropout? My idea was to up-sampling and
re-blocking
a subpatch with [readsf~] and pass signal using [outlet~] to the main canvas. In this way [readsf~] has a larger blocksize read and it is
called
more often than the main canvas.
i don't think i can follow the logic: how would having a larger blocksize that is called more often reduce audio dropouts?
if you care about reading larger chunks of the audio-file per block, you can just re-block the subpatch (without upsampling), and then the signal sent through [outlet~] will have the correct sample rate (and length, and pitch).
if you want to replace [soundfiler] with something that takes a little longer to read a soundfile into a table and therefore avoids dropouts (because it doesn't have to do all the work in a single DSP tick), you can use an upsampled (and probably reblocked) subpatch to read the soundfile with [readsf~], and write it into the table *inside* the re-blocked canvas. then access the data from outside (without re-sampling) and the data will be correct.
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list