Re: [linux-audio-user] xrun madness

Hi, all, Sorry for the length, here, but I'm out of ideas for things to try! Back in June, I wrote to the list lamenting xruns in my system using jackd and ardour with a Delta 1010LT and an Adaptec 7890 SCSI controller. I was trying out early 2.6 kernels, but ended up going back to a 2.4.23 with low latency patches, but there were still xruns with the 2.4.23 kernel. I came across info suggesting the problem was the Adaptec controller: http://eca.cx/lau/2004/06/0000.html I ended up adding an IDE drive to use for audio, and things seemed to work: http://eca.cx/lau/2004/06/0026.html I've continue fussing with the system to try and figure out the SCSI problem. "Why bother?" you ask? Well, my system is still on the SCSI Raid0 and occassionally I still get an xrun (last night, the "occasional" became "in the middle of 3 or 4 attempts to lay down basic tracks with the band" - arrggh!), even when I've shut off just about all processes. I can really pile up the xruns while recording to the IDE drive by coping a big file on the SCSI Raid0, suggesting again a problem with the Adaptec. I wrote to Justin Gibbs, who worked on the aic7xxx driver. He said that the contention expressed on the ST Audio website (referenced in the first message linked above) that the Adaptec keeps steady access to the PCI bus was "complete hogwash." He mentioned that there may be problems with the latency timer settings on the devices, so I've tried just about every possible combination of latency timer settings for the AIC7890 and the 1010LT, but nothing changes the number of xruns when recording to the SCSI Raid0 (about 30 in a 1 min recording session, 8 channels, -n 2 -p 256). So that doesn't seem to be it. Justin expressed doubts about whether the AIC7890 was the problem, but it is clear that the xruns are linked to disk writes (I monitored iostat while recording, and the xruns occured when the disks were written to). This seems rather damning, but I've found that I can record to the SCSI Raid0 with no xruns at all when running Capture only, with periods down to 128. Iostat shows the same amount of disk activity. Interestingly, running in Duplex mode on the SCSI Raid0, I cannot eliminate xruns even with the largest period possible (something like -n 2 -p 2048) - I will still get occasional xruns. In an effort to track down the problem, with Lee Revell's help (thanks, Lee!) I've tried out the recent 2.6.9-rc2-mm4-VP-S7 kernel to take advantage of its kernel latency tracing capabilities. Turning on all the preempt and latency doo-dads shows that the max kernel latency to be around 200 - 400 usec when recording to either the SCSI Raid0 or IDE disks. This kernel latency is far below the 5.8ms period time (-p 256 -r 44100). Unfortunately, I still get xruns when recording to either disk (about 30 in 30 sec of recording). The xrun diagnostics don't really tell me much, either. I get a lot of: Oct 18 22:09:38 darth XRUN: pcmC0D0p Oct 18 22:09:38 darth [<e0a316a0>] snd_pcm_period_elapsed+0x280/0x3f0 [snd_pcm] Oct 18 22:09:38 darth [<c02e1613>] schedule+0x403/0x7d0 Oct 18 22:09:38 darth [<c0133516>] handle_IRQ_event+0x36/0x70 Oct 18 22:09:38 darth [<c0111608>] mcount+0x14/0x18 Oct 18 22:09:38 darth [<e0a447f6>] snd_ice1712_interrupt+0x1a6/0x230 [snd_ice171 2] Oct 18 22:09:38 darth [<c0133516>] handle_IRQ_event+0x36/0x70 Oct 18 22:09:38 darth [<c0133c90>] do_hardirq+0x70/0xe0 Oct 18 22:09:38 darth [<c0133e24>] do_irqd+0x124/0x1f0 Oct 18 22:09:38 darth [<c0132b5b>] kthread+0xbb/0xc0 Oct 18 22:09:38 darth [<c0133d00>] do_irqd+0x0/0x1f0 Oct 18 22:09:38 darth [<c0132aa0>] kthread+0x0/0xc0 Oct 18 22:09:38 darth [<c0102779>] kernel_thread_helper+0x5/0xc Oct 18 22:09:38 darth XRUN: pcmC0D0p Oct 18 22:09:38 darth [<e0a316a0>] snd_pcm_period_elapsed+0x280/0x3f0 [snd_pcm] Oct 18 22:09:38 darth [<c02e1613>] schedule+0x403/0x7d0 Oct 18 22:09:38 darth [<c0133516>] handle_IRQ_event+0x36/0x70 Oct 18 22:09:38 darth [<c0111608>] mcount+0x14/0x18 Oct 18 22:09:38 darth [<e0a447f6>] snd_ice1712_interrupt+0x1a6/0x230 [snd_ice171 2] Oct 18 22:09:38 darth [<c0133516>] handle_IRQ_event+0x36/0x70 Oct 18 22:09:38 darth [<c0133c90>] do_hardirq+0x70/0xe0 Oct 18 22:09:38 darth [<c0133e24>] do_irqd+0x124/0x1f0 Oct 18 22:09:38 darth [<c0132b5b>] kthread+0xbb/0xc0 Oct 18 22:09:38 darth [<c0133d00>] do_irqd+0x0/0x1f0 Oct 18 22:09:38 darth [<c0132aa0>] kthread+0x0/0xc0 Oct 18 22:09:38 darth [<c0102779>] kernel_thread_helper+0x5/0xc Oct 18 22:10:10 darth XRUN: pcmC0D0p Oct 18 22:10:10 darth [<e0a316a0>] snd_pcm_period_elapsed+0x280/0x3f0 [snd_pcm] Oct 18 22:10:10 darth [<c02e1613>] schedule+0x403/0x7d0 Oct 18 22:10:10 darth [<c0133516>] handle_IRQ_event+0x36/0x70 Oct 18 22:10:10 darth [<c0111608>] mcount+0x14/0x18 Oct 18 22:10:10 darth [<e0a447f6>] snd_ice1712_interrupt+0x1a6/0x230 [snd_ice171 2] Oct 18 22:10:10 darth [<c0133516>] handle_IRQ_event+0x36/0x70 Oct 18 22:10:10 darth [<c0133c90>] do_hardirq+0x70/0xe0 Oct 18 22:10:10 darth [<c0133e24>] do_irqd+0x124/0x1f0 Oct 18 22:10:10 darth [<c0132b5b>] kthread+0xbb/0xc0 Oct 18 22:10:10 darth [<c0133d00>] do_irqd+0x0/0x1f0 Oct 18 22:10:10 darth [<c0132aa0>] kthread+0x0/0xc0 Oct 18 22:10:10 darth [<c0102779>] kernel_thread_helper+0x5/0xc If anyone can help interpret this, I'm all ears/eyes! Under this kernel, running in Capture mode does not generate any xruns, but jackd halts ardour after about a minute of recording with a "subgraph starting at ardour timed out" error. Capture mode with the 2.4.23 kernel seems to work fine recording to either disk. One more bit of info: Running jackd in verbose mode, under 2.4.23 the max usec runs around 800-1000 when there are no xruns (still well below the 5.8ms period). Under 2.4.9, the max usec run between 1100-2000 (odd that it is higher with the different kernel, but still below the 5ms). Most xruns are below 1 ms. Oh, and I _never_ get an xrun during playback, even in Duplex mode. I have a Gentoo system, so after seeing recent messages about potential issue with Gentoo, I tried booting the Demudi LiveCD to test things. I didn't get far - with no clients, qjackctl showed frequent xruns "just idling." I figured I'd stick to debugging the Gentoo system, since it seemed to be closer to working.