[chuck-users] Urgent shot in the dark -- Audible clicks when spawning shreds when SndBuf reads from disk

Kassen signal.automatique at gmail.com
Sun Nov 8 09:56:49 EST 2009


(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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20091108/7f6c1c6d/attachment.html>

More information about the chuck-users mailing list