I've got a chuck app that runs great for about thirty minutes and then starts acting flaky. Sound starts cutting out, gets progressively worse, and then within about five minutes it ceases to make any sound. It doesn't crash, it just stops making sound. When I fire up Activity Monitor (OS X) to see what's going on, there doesn't appear to be anything obvious. Memory usage climbs steadily over the 30 minutes but caps off at around 25-30 megabytes. CPU never really gets above 75% (out of 200% on my dual core computer). The application is kind of complicated, but essentially it starts up 6 shreds, each in control of their own SndBuf. Here's a quick overview of what each shred does: Request a file name from another app via OSC Load the wav file into a SndBuf Play it for a little while (<10 minutes), skipping around in the file (mostly rewinding to the beginning of the clip). Request a new file name (repeat) The sound files are 30-150k each. It cranks through over 100 sound files before problems start happening. It doesn't look like garbage collection ever happens, but it's not using that much memory. Here's the relevant bit of code that takes the OSC message and loads up the clip: oe.getInt() => int player; oe.getString() => string snd; // allocate a new sound buffer new SndBuf @=> newClip[player]; // stick the new sound in the new sound buffer snd => newClip[player].read; Anyone have any idea what's going on? Should I be destroying these SndBufs more explicitly rather than just dropping their references? The manual says memory management is automatic, but mentions something about garbage collection not being implemented quite yet. That's ok since I can restart the chuck process every once in a while, but I need to get at least a two hour performance out before I restart. If you're curious, here's a link to the project writeup (a little out of date these days): http://www.virtualjames.com/mechatronics/final-project.html Thanks, James