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/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"?
You will need JACK and the firewire backend running for most ffadomixer features to work. 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?
Make sure your /dev/raw1394 device node is read- and writeable by a normal user. Permissions for device nodes are handled by udev rules. In most distros, you should find those in /etc/udev/rules.d:
cd /etc/udev/rules.d grep 1394 * 50-udev-default.rules:KERNEL=="raw1394*", GROUP="video"
Either change the group in 50-udev-defaut.rules to some other of which you are a member, or make yourself a member of that group. The distro in this example assumes that any interesting device on firewire has to be a DV camera, hence their choice of group.
After editing the udev rules, tell udevd to re-read them (as root):
udevcontrol reload_rules
Note that you will need to log out and back in to put new group assignments in effect. (No need to reboot, though - this is ain't that other operating system :)
