(I know, I know -- I'm crazy.)
:-) this does remind me that I need to document and file a big relating to assignment and -probably- over-zealous GC that I found Friday night, a few hours before show-time.
It's 9:25am here on the East Coast of the U.S. We're onstage at 2pm
and 8pm. I have a script that receives OSC messages from a Java
program. The messages contain the string name of a file to play.
It's a simple stereo file (I'm already working with a very kludgy way
of playing stereo files--loading it twice into two buffers). But
every time I spawn a new thread, the file loads from disk and there's
an audible click, or drop in audio.
Ok, I don't have the time to hack at your code as I need to help clean up from Friday's party this afternoon. Also; my systems aren't your systems, being equipped with different drives and CPU. As this is a system-specific issue it makes no sense for me to test fixes here. But;
* First place for speedy fixes of system-overload-related clicks is increase the buffer size when starting ChucK. The price is latency, of course, but we're on a deadline.
* I think SndBuf can block-load parts of the file instead of fetching it all at once. Look into that. This sounds like the most structural solution to me but I think few people use that feature so it might have bugs.
*Pre loading all files into a big array of SndBuf's that aren't chucked to the dac will not cost CPU, just memory. In this case you'd play them by connecting them and sporking the relevant shred (remembering to disconnect them later). This won't grind things to a halt cpu-wise. It might cost a lot of memory. Verify you don't happen to have that much ram. If not consider batch-converting them all down to CD quality if they aren't already. If they are already at CD quality you could see what happens when the computer would get down to virtual memory; the OS might have special tricks there to speed things up that ChucK lacks.
Good luck!
Kas.