...

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