[PD] sfread~ droupouts / understanding buffer parameter?

[Roman Haefeli]

On Mon, 2013-04-08 at 10:08 +0200, João Pais wrote:
> Hi list,
> 
> 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~].
 
> 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.

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.

> 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.

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.

Roman