xrun when starting/stopping recordings

Hi,
i’m currently testing my system if it works with jackd and ardour. It uses the 2.6.19 kernel with the realtime patch rt9 on Ubuntu 6.10 on AMD64 with dual Opteron 165. After fiddling with the priorities i got jackd to run stable.

When no client is attached jackd runs very stable, even during heavy system load (scons -j 6 plus 2 glxgears plus heavy network traffic) without xruns. Jackd reports between 5us and about 60us max latency.

But with ardour2 from current SVN there are problems when starting/stopping recordings and also randomly while recording with short buffers. (fresh project, one 8 channel track)

Jackd reports xruns of up to 0.1ms without system load. With system load (2x glxgears) xruns of mostly about 0.1ms but up to 2ms just by moving the mouse on the desktop.

To my understanding this shouldn’t happen because the soundprocessing should not be influenced by other events/processes.

Is there something in ardour that is known to cause these delays?

Can it be avoided by changing some of ardours threads priorities? (Currently jackd and the soundcard IRQs have FIFO with priority 95, which is above all others but the realtime clock and migration).

What buffer size are you running jack at, and what video card are you running on which drivers? Which soundcard are you using, and have you fiddled with the number of periods in jackd?

Video cards can hog the bus if used with “evil” (=optimized beyond what the PCI/AGP spec allows). Also, if your video card uses shared memory it might compete for the system memory.

“To my understanding this shouldn’t happen because the soundprocessing should not be influenced by other events/processes.”

Answer: There’s a lot more going on in Ardour than just sound processing. Ardour also needs to write the data to disk.

Also, your stable test case sounds like you have no jack clients connected, right? That is not a reliable test case at all because it eliminates the jack callback graph from the real world equation.

What buffer size are you running jack at, and what video card are you running on which drivers? Which soundcard are you using, and have you fiddled with the number of periods in jackd?

I used the buffersize of 16 for the test with the xruns. When increasing it to 128 the xruns go away but the reported usecs still range from under 100us to over 500us when ardour is connected. And that without any effects enabled in ardour.

I use this command to start up jackd:

jackd -v -R -P 85 -t 1000 -u -d alsa -C hw:2 -i 12 -P hw:2 -o 10 -p 128 -n 2 -r 41000

The version of jack is:

jackd version 0.102.29 tmpdir /tmp protocol 16

Because i have two Phase88s, i created a multidevice like this:
http://www.sound-man.co.uk/linuxaudio/ice1712multi.html

But it doesn’t make much of a difference if i use only one soundcard or the multidevice.

Video cards can hog the bus if used with “evil” (=optimized beyond what the PCI/AGP spec allows). Also, if your video card uses shared memory it might compete for the system memory.

It’s an Nvidia PCIe card with the latest nvidia-drivers. It should use it’s own memory.

05:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600] (rev a2) (prog-if 00 [VGA]) Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at e8000000 (32-bit, non-prefetchable) [size=64M] Memory at e0000000 (64-bit, prefetchable) [size=128M] Memory at ec000000 (64-bit, non-prefetchable) [size=16M] [virtual] Expansion ROM at ed000000 [disabled] [size=128K] 01:07.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02) Subsystem: TERRATEC Electronic GmbH PHASE88 Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at 8000 [size=32] I/O ports at 8400 [size=16] I/O ports at 8800 [size=16] I/O ports at 8c00 [size=64] 01:08.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02) Subsystem: TERRATEC Electronic GmbH PHASE88 Flags: bus master, medium devsel, latency 32, IRQ 16 I/O ports at 9000 [size=32] I/O ports at 9400 [size=16] I/O ports at 9800 [size=16] I/O ports at 9c00 [size=64]
Answer: There’s a lot more going on in Ardour than just sound processing. Ardour also needs to write the data to disk.

Sure, but these things shouldn’t be affecting the processing time for the callback. The callback should not be interrupted because it runs at the highest priority (except for the rtc) and it should not wait for some other thread to finish (disk or graphic thread).

Also, your stable test case sounds like you have no jack clients connected, right? That is not a reliable test case at all because it eliminates the jack callback graph from the real world equation.

Yes, that’s right.

Is the callback completely deactivated?

When i just connect the inputs to the outputs via jack_connect, i get this pattern under load when moving the mouse:

load = 1.4587 max usecs: 44.000, spare = 2858.000
load = 1.1945 max usecs: 27.000, spare = 2875.000
load = 2.4580 max usecs: 108.000, spare = 2794.000
load = 1.9182 max usecs: 40.000, spare = 2862.000
load = 1.6138 max usecs: 38.000, spare = 2864.000
load = 1.5822 max usecs: 45.000, spare = 2857.000
load = 1.5148 max usecs: 42.000, spare = 2860.000
load = 1.4121 max usecs: 38.000, spare = 2864.000
load = 2.9114 max usecs: 128.000, spare = 2774.000
load = 3.6439 max usecs: 127.000, spare = 2775.000
load = 2.4422 max usecs: 36.000, spare = 2866.000
load = 1.6001 max usecs: 22.000, spare = 2880.000
load = 1.2480 max usecs: 26.000, spare = 2876.000

Something still seems to interrupt or delay jack, even if it is only a portion of what happenes when ardour is connected.

A few things come to mind:

First, do not select the playback and capture devices separately, just select hw:2 as the alsa device (via -d alsa -d hw:2).

Second, you might want to try and remove input and output port counts - it’s a lot better to let alsa select. ice1712 devices are known not to work at all when those parameters are not 12/10. This shouldn’t really matter, but you might want to try it anyway.

Third, I don’t know if it was a typo, but 41000Hz is quite an unusual sampling rate - I wouldn’t be all too surprised if the soundcard doesn’t even support it.

Fourth, a buffersize of 16 is truly pushing it! It’s something you can achieve with Linux on very strict system design. But it’s definitely something that you need to strive for.

Fifth, the “pattern” you get from jack is what jackd outputs under normal operations (no xruns) when -v (verbose) is selected. I don’t see what’s wrong there.

Have you used “ps -Leo pid,rtprio,cmd” (or equivalent) to look at the RT priorities of tasks and IRQ’s in your system? It might reveal some information.

First, do not select the playback and capture devices separately, just select hw:2 as the alsa device (via -d alsa -d hw:2).

Second, you might want to try and remove input and output port counts - it’s a lot better to let alsa select. ice1712 devices are known not to work at all when those parameters are not 12/10. This shouldn’t really matter, but you might want to try it anyway.

The seperate selections were because i tested with the multi-device which cannot be used as playbackdevice at the same time because some bug with the 12/10-channel thing.

The command would then be:

jackd -R -P 5 -t 1000 -u -d alsa -C multi -P hw:2 -p 64 -n 2 -r 96000

Yes, alsa automatically selects the right number. But it doesn’t make a difference.

Third, I don’t know if it was a typo, but 41000Hz is quite an unusual sampling rate - I wouldn’t be all too surprised if the soundcard doesn’t even support it.

Typo, but apparently works.

Fourth, a buffersize of 16 is truly pushing it! It’s something you can achieve with Linux on very strict system design. But it’s definitely something that you need to strive for.

I used this as an example because then the xruns appear much faster. With a buffer size of 256 there are almost no xruns… but still there are some.

Fifth, the “pattern” you get from jack is what jackd outputs under normal operations (no xruns) when -v (verbose) is selected. I don’t see what’s wrong there.

Can the debug output with “-v” block jackd?

This could be a problem when printf has to wait for something.

Using this:

echo “0” > /proc/sys/kernel/preempt_max_latency

And later this:

cat /proc/sys/kernel/preempt_max_latency

…delivers normally values of 15 to 30, but then sometimes it goes up to higher numbers exceeding 1000us. Then sometimes an xrun has happened, sometimes not.

Compiling the kernel in background doesn’t affect this value, so disk-io shouldn’t be a problem. Heavy network activity also appears to have no effect.

But starting 2 glxgears makes the value go up over 300, when the glxgears are running the max latency stays low. Maybe the video driver is the source of the problems.

For now i’d say it is a problem with the realtime kernel and the nvidia driver. Connecting ardour apparently just made the problem occur more likely.

I’ll compile the newest 2.6.20-rc6-rt4 kernel and try to turn on debugging.

have you tuned the PCI max latency settings for your devices? nvidia h/w is known to hog the bus, and requires tweaking to do very low latency audio. you seem tohave some idea what you're doing, so i'll just show you the script i use to tune my system(s):

#!/bin/sh

case $1 in
     start)
           # "open up" the PCI bus by allowing fairly long bursts for all devices, increasing performance
           setpci -v -s "*:*.*" latency_timer=b0

           # maximise latency for RME Hammerfall, thus allowing
           # more data per PCI transfer and minimizing xfuns
           setpci -v -s 03:00.0 latency_timer=ff
           # ditto for the onboard AC97 audio interface
           setpci -v -s 00:1f.5 latency_timer=ff
esac

exit 0

that lives in /etc/rc.d/init.d/pcilatency and is run at system startup. without it, the nvidia driver and h/w will destroy my attempts to get low latency from either of the two interfaces installed.

Thanks for the idea, but i think this here is a different problem.

It’s a PCIe card. The two soundcards are PCI cards. They are the only PCI cards in this system. (Mobo is Gigabyte K8N Ultra-9)

The only devices to be affected by setpci are the two soundcards and the onboard-firewire-chip (nothing attached). All other cards report latency=0.

Disabling firewire wont hurt…


EDIT:

Apparently running the “nv” driver instead the “nvidia” driver and using the latest kernel (2.6.20-rc6-rt4) helps with the latency problem. Sadly it’s incompatible to the driver from nvidia, so no dual-configuration is possible without rebooting and TwinView doesn’t work with “nv”.

Using a buffer size of 64 samples the latency stays in between 70us and 200us with ardour connected.

The test program

sudo ./cyclictest -p 99 -t 5 -n -r -c 1

from

http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO

reports about 11us average and 60us maximum latency.

Still not enough to explain the 70us-200us range from jackd, but much better than before.