geiger at epy.co.at
Tue Mar 13 17:15:04 CET 2001
On Tue, 13 Mar 2001, Linium wrote:
> I have a dual 400 with scsi and fast hardisc and 128 mb.
> performances reported were with the standard readsf~ object.
Should not be a problem then.
> Meanwhile I have tested the sfread~ and sfplay~ provided in your
> external lib, and I have to say they seem to work better.
> EXCEPT that they load everything in ram, aren't they ?
> I have just made the test to open 8 tracks or so with sfread~ and pd memory
> size kept growing until it dies with "broken pipe".
none of them read the data into memory.
sfread~ uses mmap, which made it very simple implementing a varyspeed
player. It actually should not crash, ( I couldn't get it to crash with 8
stereo files of 3min each), but it starts swapping, because it makes
linux believe that the soundfiles are in memory, but just swapped out.
so, well it does kind of use the memory, but by expanding the virtual
Your crash may be a bug in the kernel too. I have to do extensive
testing which probably will not happen because my brain is full of other
sfplay was written by Winfried Ritsch in order to optimize playback of
multiple files, so it is the one that you probably want to use.
(it is the one I am using if I want to playback multiple files).
the difference between sfplay~ and the builtin readsf~ is, that readsf~
is multithreaded and guaranties not to block pd ....
maybe thats a problem ?
More information about the Pd-list