[chuck-users] sndbuf cleanups?

[James Hughes]

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