On Mon, Aug 03, 2009 at 09:39:16AM -0700, Kim Cascone wrote: How often does this happen? At a fairly regular interval? I'm assuming also that you have the interrupt for your iMic set to a higher priority than jackd using chrt or some such. If that isn't done, then it kind of defeats the whole purpose of having a RT kernel. If the priorities aren't set right, then some other process or interrupt can grab the CPU from you when JACK is trying to write data out to the interface, or since you're playing back, when the interface might be trying to interrupt JACK for some reason. That might be the first-order issue. I check as follows: do lsusb to find out what Bus your iMic is on. Then cat /proc/interrupts and check which interrupt number that Bus is on (i.e. usb1, usb2, etc.). Then check what priority that interrupt is at, i.e. with "ps Haxo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort=-rtprio" (and of course I've written a hairy nasty bash script to do all the above nonsense, and it runs every time I start JACK). As a second-order issue, I usually turn off all daemons on any performance machine. A short list (several years out of date, unfortunately, since systems have accreted so much cruft in the last few years) is this: for i in cupsys hplip portmap nfs-client nfs-common openbsd-inetd lpd bluetooth bluetooth mzscheme timidity irqbalance; do sudo update-rc.d -f $i remove sudo /etc/init.d/$i stop done It would probably be bad if a daily cron job like updating your man or find or apropos stuff were running while you were trying to do a show. I commented out everything in /etc/crontab (an alternative would be to add "cron" to that list above of daemons to stop). Getting down to the much higher-order issues: try without your Wifi running. Wifi drivers and/or hardware can tend to get ugly. There may be another USB device that is not-well-behaved but is on the same interrupt as the iMic. -ken