Opened QJackCtl and configured the device and hit "start" to enjoy the xrun free run. But it just took a couple of seconds before the complaints started to pour in:
Code: Select all
delay of 20029.000 usecs exceeds estimated spare time of 2868.000; restart ...
15:49:18.956 XRUN callback (1).
delay of 19965.000 usecs exceeds estimated spare time of 2868.000; restart ...
delay of 19956.000 usecs exceeds estimated spare time of 2868.000; restart ...
delay of 19960.000 usecs exceeds estimated spare time of 2868.000; restart ...
Yikes! I said to my self and then remembered something about shared IRQ and I/O-APIC that I once read (probably last week or so). So I decided to investigate it:
Code: Select all
$ cat /proc/interrupts
CPU0 CPU1
0: 31760 31650 IO-APIC-edge timer
1: 36 33 IO-APIC-edge i8042
9: 0 0 IO-APIC-fasteoi acpi
16: 8052 8112 IO-APIC-fasteoi libata, uhci_hcd:usb3, uhci_hcd:usb8, nvidia
17: 3530 3468 IO-APIC-fasteoi ICE1712, eth0
18: 3 2 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb7, ohci1394
19: 5871 5904 IO-APIC-fasteoi libata, libata, uhci_hcd:usb6
21: 1260 1260 IO-APIC-fasteoi uhci_hcd:usb4
23: 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5
NMI: 0 0
LOC: 63352 63311
ERR: 0
First, I tried to see if there was any changes in BIOS that I could make, but the only things I found was disabling the parallel port, the com port, HDA-Intel and the floppy controller (the output above is from after this disabling business was done). No way to otherwise alter the IRQs.
Second, I re-opened the case and moved the PCI-card to the other free slot. But this only resulted in the ICE1712 getting IRQ 16 and thus sharing it with pretty much everything else.
Thirdly, I just disabled the IOAPIC option in BIOS to see what happened. All it did was making the system unbootable (timing out when trying to identify devices).
So, where to go from here?
I guess the natural next step would be disabling the built-in NIC, replacing it with a PCI or PCI-E NIC, so that ICE 1712 will have IRQ 17 to it self.
Are there any good current resources on the kernels handling of interrupt vectors on I/O-APIC systems? All information I could find was a couple of years old. But I guess I have to get the device on its own IRQ first no matter what.