chucK: compiling and optimizing

chucK is a realtime sound synthesis environment that compiles on linux by interfacing with ALSA. I fell in love with it while in art school and continued to use it over the last 6 years.

Dan Yocom put the galileo/chuck binaries compiled for galileo here

If you want give compiling chuck yourself a try, you need is alsa-dev. You can get that package by adding the following (with you Galileo connected to the internet) to '/etc/opkg/base-feeds.conf'

src all     http://iotdk.intel.com/repos/1.1/iotdk/all
src quark   http://iotdk.intel.com/repos/1.1/iotdk/quark
src i586    http://iotdk.intel.com/repos/1.1/iotdk/i586
src x86     http://iotdk.intel.com/repos/1.1/iotdk/x86

Then run opkg update and opkg install alsa-dev

Once you have chucK up and running, optimizing chucK for Galileo (as specified by the current developers) The biggest way to reduce it is to change the block size. The adaptive flag is used at run-time, so you would run it like this:

chuck --adaptive:256 yourfile.ck

Note that if there are feedback loops between your ugens (e.g. adc => Delay d => dac; d => Gain fb = d;) adaptive will cause these to behave incorrectly if the feedback delay is less than the adaptive buffer size (e.g. 256 samples in the invocation above). Provided you can live with that limitation, --adaptive provides a significant speed increase and may be enough for your needs.

If you still need more headroom, make sure you aren't using any more reverb ugens than you actually need (1 for mono, 2 for stereo is almost always fine) -- reverbs are relatively expensive. If you are using a lot of oscillators, consider TriOsc/SawOsc/SqrOsc instead of SinOsc (SinOsc calls C sin() every sample whereas the others only use basic arithmetic).

You can also increase the adaptive buffer size or the audio buffer size (--bufsize:N), though these will result in higher latency which may be undesirable depending on your application. You can decrease the sample rate (e.g. --srate:22050) but this will start to sound bad very quickly if you go lower than 22050 and even that is pretty bad in a lot of situations.

Lastly, consider limiting your control rate to every 10::ms or so (i.e. if you are running ChucK code every so often, only run it every 10::ms- instead of a more frequent interval. If you are processing HID/serial input, only process those every 10::ms). Of course you can raise or lower this rate to meet the needs of your specific application.

More information can be found from this discussion on the chucK forum.