Frequently Answered Questions

Why do I need kernel >= 2.6.21 for FFADO?

To obtain good synchronisation, we needed very specific functionality that wasn't present in the linux1394 kernel stack, so we wrote it (not a big deal). The patch was submitted to mainline kernel and will be included as from 2.6.21.

Note: Ubuntu Feisty contains a patched 2.6.20 kernel that already includes this functionality.

The most recent FFADO versions contain a build-time configuration option that provides a workaround for this, which should make it work with older kernels. For good performance it is however recommended to upgrade.

What is the right pronounciation of ffado?

According to Pieter Palmers its like "fah dough".

Arnold Krille thinks it should be "f-fah dough".

Jack SVN doesn't contain FFADO support

Upgrade to a more recent version of jack that includes the 'firewire' backend.

Jack complains about an incompatible FFADO version

If you experience some error like this:

 firewire ERR: Incompatible libffado version! (libffado 1.999.17-981)

There is a version mismatch between jack and FFADO. Upgrade both libffado and jack to the newest version. This should only happen when you use development versions of ffado.

FFADO doesn't recognise my device

If your device is a BeBoB device, it could be that the ID's for it are not yet present in the code. The device is recognized using the vendor and model id which is exposed by the config rom. You can add the line to the text file usually found at /usr/share/libffado/configuration and in older versions at /usr/local/share/libffado/ffado_driver_bebob.txt

Why did ffado switch from make/auto* to scons?

There are a number of reasons (accompanied by big discussions on ffado-devel) but the basic reason is/was: auto* was hard to maintain for the current devs and someone actually stepped up to do the porting to scons. Its something that can be called as a do-cracy: the one who actually does it gets to make the decision...

Why is the CACHEDIR defined to $HOME/.ffado and not something like /usr/share/libffado or /var/cache/libffado?

Excerpt from an IRC-session:

[22:17] <wagi> of course the other solution would be to set $CACHEDIR in scons correctly
[22:18] <wagi> stupid idea wont work of corese
[22:19] <kampfschlaefer> wagi: which implies that scons creates the dir. which is not possible if its in homedir or any */tmp. And it has to be in $HOME or /tmp because otherwise its not writeable by the user (useless for caching...)
[22:20] <wagi> kampfschlaefer: note that HOME is not defined until the concrete users starts ffado. that means it can't be deduce during compile time
[22:22] <kampfschlaefer> wagi: And distributions compiling ffado to create binary packages don't know the names of the actual users. And even compiling the source scons cant detect all the 'real' users from parsing /etc/passwd

How do I really clean the build-cache of scons?

There are two steps of cleaning the cache: 1. "rm -Rf cache/objects" will removed the cached versions of all built files 2. "rm -Rf cache" removes everything cached including config-results and settings.

Why doesn't my ffadomixer do anything besides "identify"?

Sometimes you will need JACK and the firewire backend running for ffadomixer features to actually work. This is the case for Focusrite Saffire devices and for (most) MOTU devices.

Jonathan Woithe explains:

... the MOTU interfaces use the iso data stream to communicate device status back to the computer. As a result it is not possible to drive their onboard mixers and the like without the iso stream running. Now, the mixer application *could* start its own iso stream, but what would then happen if the user wanted to start something requiring jackd? They would have to exit the mixer application, start jackd and then restart the mixer - assuming the mixer would be smart enough to lock into a running jackd if it finds one. All rather messy.

The Focusrite Saffire devices only allow mixer and configuration changes when the audio streams are running. The hardware is simply designed this way. This means that jack (or any other ffado client) has to be running for configuration changes to have any effect.

Why can I run ffado-dbus-server only as root?

Check out KernelModuleAndPermissions.

How many devices can I use at the same time?

Original question:

Has anyone tried using 4 or more Saffire PRO at once with jack/libffado? Do you have any advice on the configuration to use?

You are not likely going to be able to use more than 4 devices on the same host controller. This due to the fact that most host controllers have only 4 "DMA contexts" in each direction (send/receive). One for each direction is needed for ASYNC traffic (ir I remember correctly), and every ISO stream needs one. One Saffire requires an ISO stream in each direction, hence using one context per direction. IOW: with 4 contexts you can drive 3 devices.

You can figure out how many contexts your card has using

dmesg | grep ohci1394

This gives e.g. the following lines:

[    4.092000] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[ecdfb800-ecdfbfff]  Max Packet=[2048]  IR/IT contexts=[4/8]
[    4.144000] ohci1394: fw-host1: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[ecbff000-ecbff7ff]  Max Packet=[2048]  IR/IT contexts=[8/8]
[   15.316000] ohci1394: fw-host2: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[8c000000-8c0007ff]  Max Packet=[2048]  IR/IT contexts=[4/4]

In which the {IR/IT contexts} indicates the number of contexts available in each direction.

These numbers are for the following host controllers:

0e:00.0 FireWire (IEEE 1394): Texas Instruments XIO2200(A) IEEE-1394a-2000 Controller (PHY/Link) (rev 01)
04:00.0 FireWire (IEEE 1394): NEC Corporation uPD72874 IEEE1394 OHCI 1.1 3-port PHY-Link Ctrlr (rev 01)
03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)

It e.g. means that the Texas Instruments controller can accommodate 4 receive and 8 transmit contexts, meaning a total of max 3 devices.

Which versions of jackd can I use on which version of libffado ?

Jackd versionFFADO versions
svn (decembre 2008)
svn rev XX