Troubleshooting FFADO

Reset your interface

Most FireWire gear has a tendency to end up in weird states when something unexpected (like a JACK crash) happens. This can lead to frustrating erratic behaviour where stuff works sometimes.

To be sure your interface isn't locked in some half-usable state, power-cycle the device (not the whole computer!) to make sure it's good to go. If it's bus-powered, unplug the FireWire cable, wait a few seconds, and re-insert. Then try again.

If you find that power-cycling helps to solve your problem, good. But it can become tedious. In many cases, a bus reset works just as well, and it can be done in software, without wearing out your FireWire socket:

$ ffado-test BusReset

Try it. It's especially useful if you don't have easy access to the device (i.e. if it's in a closed rack or machine room, or you are remoting into your studio machine).

Make sure your FireWire hardware is found

You already checked the presence of the kernel module and the device permissions, right?

Connect your FireWire audio device. To make sure it is visible on the bus, take a look at the tests/ subdirectory in your FFADO build tree. There should be a little diagnostic utility named test-ffado.

$ cd /your/ffado/build/directory/
$ cd tests/
$ ./test-ffado Discover

It will tell you whether the FireWire bus is accessible, and if any devices have been found. If you can't make sense of the output, post it to the FFADO user mailing list and ask for help.

The utility also has other useful options. ./test-ffado --help will list them.

It might also be interesting to take a look at the system log while you are plugging in your device. You might need root privileges to do that:

$ su -
[type your root password here]
$ tail -f /var/log/messages
[some output]
[now plug in your audio interface]
Oct 18 19:58:17 kleineronkel kernel: ieee1394: Node added: ID:BUS[0-01:1023]  GUID[00130e010003009e]
Oct 18 19:58:17 kleineronkel kernel: NOTE: The dv1394 driver is unsupported and may be removed in a future Lin
ux release. Use raw1394 instead.
Oct 18 19:58:17 kleineronkel kernel: ieee1394: raw1394: /dev/raw1394 device initialized
Oct 18 19:58:18 kleineronkel kernel: ieee1394: Node suspended: ID:BUS[0-01:1023]  GUID[00130e010003009e]
Oct 18 19:58:23 kleineronkel kernel: doh, someone wants to mess with state set
Oct 18 19:58:23 kleineronkel kernel: ieee1394: Node changed: 0-01:1023 -> 0-00:1023
Oct 18 19:58:23 kleineronkel kernel: ieee1394: Node resumed: ID:BUS[0-00:1023]  GUID[00130e010003009e]
Oct 18 19:58:23 kleineronkel kernel: ieee1394: Node changed: 0-00:1023 -> 0-01:1023
Oct 18 19:58:23 kleineronkel kernel: ieee1394: Node changed: 0-01:1023 -> 0-00:1023
Oct 18 19:58:23 kleineronkel kernel: ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[00130e010003009e]
Oct 18 19:58:28 kleineronkel kernel: doh, someone wants to mess with state set
Oct 18 19:58:28 kleineronkel kernel: ieee1394: Node resumed: ID:BUS[0-00:1023]  GUID[00130e010003009e]
Oct 18 19:58:28 kleineronkel kernel: ieee1394: Node changed: 0-00:1023 -> 0-01:1023
Oct 18 19:58:28 kleineronkel kernel: ieee1394: Node changed: 0-01:1023 -> 0-00:1023
Oct 18 19:58:28 kleineronkel kernel: ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[00130e010003009e]
Oct 18 19:58:33 kleineronkel kernel: doh, someone wants to mess with state set
Oct 18 19:58:33 kleineronkel kernel: ieee1394: Node resumed: ID:BUS[0-00:1023]  GUID[00130e010003009e]
Oct 18 19:58:33 kleineronkel kernel: ieee1394: Node changed: 0-00:1023 -> 0-01:1023
Oct 18 19:58:34 kleineronkel kernel: ieee1394: Node changed: 0-01:1023 -> 0-00:1023
Oct 18 19:58:34 kleineronkel kernel: ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[00130e010003009e]
Oct 18 19:58:38 kleineronkel kernel: ieee1394: Node changed: 0-00:1023 -> 0-01:1023
Oct 18 19:58:38 kleineronkel kernel: ieee1394: Node resumed: ID:BUS[0-01:1023]  GUID[00130e010003009e]

If you can't make sense of what you see, post the relevant lines of the log to the user mailing list.

Another source of information is the kernel message buffer. It's as low-level as you can get:

$ dmesg | less

In order to quickly find the relevant lines, either hit <END> and scroll back up to see the most recent messages, or type "/" (the seach commmand) and "1394" to look for lines about your FireWire interface (the standard name of which is "IEEE 1394"). Hit <q> to quit.

Check your interrupts

If you want to achive really low latency, you need to make sure that the interrupt line (IRQ) for the IEEE 1394 port is not shared with another device under high load. To check this, do

$ cat /proc/interrupts
           CPU0
  0:    1459348   IO-APIC-edge      timer
  1:      32119   IO-APIC-edge      i8042
  8:          1   IO-APIC-edge      rtc0
  9:        420   IO-APIC-fasteoi   acpi
 12:     357681   IO-APIC-edge      i8042
 14:     378389   IO-APIC-edge      ata_piix
 15:          0   IO-APIC-edge      ata_piix
 16:    3606467   IO-APIC-fasteoi   uhci_hcd:usb1, yenta, i915@pci:0000:00:02.0, eth0, ohci1394
 17:        710   IO-APIC-fasteoi   uhci_hcd:usb2, mmc0
 18:        426   IO-APIC-fasteoi   uhci_hcd:usb3
 19:      11119   IO-APIC-fasteoi   uhci_hcd:usb4, ehci_hcd:usb5
 21:     203452   IO-APIC-fasteoi   ipw2200
 22:     262623   IO-APIC-fasteoi   Intel ICH6
 23:          0   IO-APIC-fasteoi   Intel ICH6 Modem
NMI:          0   Non-maskable interrupts
LOC:    1457733   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

The relevant line is the one containing the "ohci1394" driver. FIXME: What other modules are there? Does this apply to the new firewire stack as well?

As you can see, the interrupt is shared with a USB hub, a wireless interface, an ethernet interface and a cardbus slot (the latter is unavoidable, since it is a cardbus FireWire card). With a setup such as this (common with notebooks), you should disable the wireless and wired networks and move essential USB gear to one of the other hubs.

Kernels with low-latency patch allow each IRQ handler to be prioritised individually. Some people have reported success with this, but this is definitely very, very advanced trickery and not for the faint of heart. see also: LatencyTuning