[LAU] Jack issue
ken at restivo.org
Wed Aug 5 02:44:42 EDT 2009
On Mon, Aug 03, 2009 at 09:39:16AM -0700, Kim Cascone wrote:
> my config:
> Dell Studio
> Ubuntu 9.04
> rt kernel 126.96.36.199-rt15-rt
> jackd version 0.116.1 tmpdir /dev/shm protocol 24
> Ardour 2.7.1 (built from revision 4296)
> USB iMic audio interface
> KOrg nanoKontrol
> cpufreq-set - both cpu's are set to 2.0GHz and userspace
> I'm trying to get Jack and Ardour set up/optimized for my fall tour
> I'm using the rt kernel as stated above
> my Jack settings are 44.1kHz: frames 512: periods 5
> latency is not a huge issue for me since I'm only playing back audio for
> a live mix situation
> and xruns in Jack seem to be tamed to 0 during playback
> my Ardour session is 30 minutes in length, has 8 tracks of audio, and
> the fader levels are assigned to the nanoKontrol
> everything works fine for the session except at some random point after
> playing for a while I get a single short burst of AM sideband noise,
> like I'm multiplying the audio on the mix buss by another audio signal
> it doesn't happen (so far) more than once per session and it doesn't
> seem to be correlated to anything like mix buss levels or clipping on a
> single channel etc
> is there a setting in Jack that I'm overlooking or has anyone
> experienced a similar intermittent burst of noise in playback with
> similar Jack settings? or if this topic has already been discussed can
> someone point me to a link in the archives? I wasn't able to find
> anything on a cursory search
> -- also, I started Ardour from command line when Jack wasn't running
> and I got three panels in the open dialog box -- one of them being a
> Audio Setup panel
> -- is there a way to see this panel after starting Ardour with Jack
> already running?
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
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.
More information about the Linux-audio-user