glitches in audio with no xruns reported...

I’ve been attempting to get ardour to work for a project and have managed to get xruns to a minimum. However, I tried recording a two channel input and there are glitches in the audio, even when no xruns are reported. Checking the settings in qjackctl, there seems to be an option for an xruns threshold so I assume these glitches are xruns that are just not being reported. So how can get rid of these glitches/xruns?

I have added the user to the audio group and have the following settings in limits.conf:

@audio - rtprio 70
@audio - nice -20
@audio - memlock 384138

I am running Jack 0.109.2 and Ardour 2.3 on an HP Compaq NC6000 1.6GHz 500MB laptop with Ubuntu Hardy 8.04 and the 2.6.24-28-rt kernel.

I am starting jackd with:

$ jackd -R -p128 -dalsa -dhw:1 -r41000 -p1024 -n3

and I am using a Behringer UCA202 usb interface.

This is the output from jack:

jackd 0.109.2
Copyright 2001-2005 Paul Davis and others.
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support.
loading driver …
apparent rate = 41000
creating alsa driver … hw:1|hw:1|1024|3|41000|0|0|nomon|swmeter|-|32bit
control device hw:1
configuring for 41000Hz, period = 1024 frames (25.0 ms), buffer = 3 periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 3 periods for capture
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 3 periods for playback

**** alsa_pcm: xrun of at least 0.362 msecs

Finally, I have read elsewhere on these forums about IRQ’s. Below is the output from cat /proc/asound/cards and cat /proc/interrupts - I assume my audio interface is on interrupt 10? Should this be changed?

$ cat /proc/asound/cards
0 [I82801DBICH4 ]: ICH4 - Intel 82801DB-ICH4
Intel 82801DB-ICH4 with AD1981B at irq 11
1 [default ]: USB-Audio - USB Audio CODEC
Burr-Brown from TI USB Audio CODEC at usb-0000:00:1d.0-1, full s

$ cat /proc/interrupts
0: 3583855 XT-PIC-XT timer
1: 8796 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
3: 3 XT-PIC-XT
4: 3 XT-PIC-XT
5: 3 XT-PIC-XT
6: 5 XT-PIC-XT floppy
7: 1 XT-PIC-XT parport0
8: 3 XT-PIC-XT rtc
9: 5178 XT-PIC-XT acpi
10: 939403 XT-PIC-XT uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, ehci_hcd:usb4, yenta, yenta, yenta
11: 202527 XT-PIC-XT wifi0, Intel 82801DB-ICH4
12: 359012 XT-PIC-XT i8042
14: 87946 XT-PIC-XT libata
15: 36960 XT-PIC-XT libata
NMI: 0 Non-maskable interrupts
LOC: 0 Local timer interrupts
RES: 0 Rescheduling interrupts
CAL: 0 function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0

@james: this is not an answer to your problems, but I’d like to point out that on the website, on the 5th of December 2008, it was written Nobody should be using 0.109.2 within a few weeks, and even that is only to allow for distributions to update.. Something to consider.

Paul, thanks for the reply. The reason I am running 0.109.2 is because I’m running Ubuntu Hardy. I tried compiling 0.118.0 but it failed to compile with my old version of alsa. The reason I’m running Hardy is because of the 3d acceleration provided by the proprietary drivers for the GPU which are only supported in the old version of xserver, argh! Maybe it’s time for a new laptop…

this is one of the biggest problems with integrated package/repository based distributions. the needs of the typical user of a general purpose distro are not well aligned with the needs of people using rapidly evolving software.