hard disk life and sfplay vs buffer
I recently built a patch that uses sfplay~s to play 13 looping sound files of various lengths at the same time (all are preloaded into one sflist~). I made the choice to use sfplay~ rather than buffer~ (disk reading versus RAM as I understand it) as it seemed likely that some of the files may be up to or over 5 mins in length and sflist~ works really nicely for my save and recall feature.
The thing is, that although the patch seems to run really well, the hard drive understandably makes some pretty horrible sounds. It makes me wonder what would happen if I left this running for days on end and is it significantly shortening the life of my hard drive?
I expect using buffer~ instead would probably have been just fine with my 4GB machine, but now it means rewriting most of the patch. So I guess the questions are: are my worries unfounded and should I have just gone with the RAM option rather than disk option? Lets say 10 of the audio files are 2 mins and 3 are 6 mins, how much RAM are we talking here?
Playing sounds from RAM will not only eliminate the noise of the HD, it will also significantly reduce the percentage of CPU used. The patch might take a bit longer to load, but that's a minor drawback.
With 4 GB it should be fine. I played 8-channels sounds of 10 minutes on a weaker computer.
One hour of audio is
60 seconds times
60 minutes times
44100 samples per second times
2 channels (for stereo) times
4 bytes per sample* equals
1270080000 bytes equals
about 1.183 gigabytes
* 2 bytes per sample for CD-quality audio, but MSP stores all signal data as 4-byte floats
maybe try how high you can set the diskbuffer argument, so you don't need to rewrite your patch.
Hey, sorry been awol for a bit.
Thanks for the interesting replies. I remade the patch using the fantastically useful [polybuffer~] and it runs great with my current setup. I've now got a pretty good way to test out disk vs RAM too!