[PD] sfread~ droupouts / understanding buffer parameter?

João Pais jmmmpais at googlemail.com
Mon Apr 8 12:03:56 CEST 2013

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


More information about the Pd-list mailing list