I have a patch with around 80 sfread~s, who read audio files between
8-16
seconds (each sfread reads always the same file). But I noticed that
there
are often enough small audio droupouts when running the patch. After
adding a buffer value of 1e+6 (like in the help patch) the playback was
better, but not yet perfect.
There is no [sfread~] class in current Pd-extended (0.43.4). Do you have
an older version of Pd-extended? From which library is that class? I can
only find moonlib's [sfread2~] and zexy's [sfplay~] and, of course, the
built-in [readsf~].
stupid, I use readsf~, not sfread~. Should have checked the patch.
So I wanted to ask: how does the buffer parameter work exactly? How can
one choose the best value for it? Does someone has an example patch, or
something written somewhere?
At least in the case of [readsf~] it is not that complicated. When
opening the file (with the 'open' message), [readsf~] reads as much data
from the file as fits into the given buffer. When finally playing the
file, it doesn't have to wait for the disk to deliver the data as the
data is accessible quickly from random access memory.
So I could give as buffersize 705600, which is roughly the bit size of a
8s mono file with cd quality? This would avoid the problem for all smaller
files with no prob?
Or just set it to 1411200 - 16s, the longest duration?
Does you patch wait between opening the files and playing them? If not,
try to open the files a short while before you play them, so that the
buffers have time to fill.
for the time being it doesn't. When I wrote the patch this problem didn't
happen before, although I did it in xp - now am using w7 and debian
squeeze (the problem exists in both systems). The number of players is
dynamic, maximum ~80.
But this problem happens also when a different number of players are
working. So I can't establish a direct correlation between number of
active readsf and audio dropouts.
The sfread~s don't work all simultaneously, maybe maximum of 20 sfread~s
might be working at the same time.
To me it sounds like your disk is too slow to deliver the requested data
in time. I found it is much more efficient to read from - for instance -
4 16-channel files than to read from 64 single-channel files. The
latter causes much more seeks as the 64 files might be spread all over
the disk. Of course, this is a non-issue if you have a SSD.
Yes. Restructuring the patch isn't an option in this case, the sound must
be saved in different files.
I don't know about Windows, but in Linux usually recently read files are
cached in the free areas of the memory. The second time you read those
files, the harddisk isn't involved, provided there is enough free memory
available which mitigates problems you describe. IIRC, I never had
problems playing 80 channels at the same time, though I haven't tried
with 80 separate single-channel files. And this is with a few years old
hard-disks.
This is a rec-play piece, so the files should be read only once each time
it is performed. Memory isn't a problem at all, as the total space in the
disk is around 80Mb.
João
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
