FireWire kernel module and device permissions


  1. Kernel drivers used by FFADO
  2. Checking for the kernel modules
  3. Checking permissions of /dev/raw1394
  4. Checking permissions of /dev/fw*
  5. Further general FireWire troubleshooting

This page explains what it takes for FFADO to be able to control FireWire audio hardware via the respective Linux kernel mechanisms. Most if not all of this should be taken care of for you already in the stock system configuration of your Linux distributor and FFADO packager. But due to the specialist nature of FireWire audio, something may still be amiss. In that case, before you start going through the steps in this document, first run the command line tool ffado-diag. This may already reveal some common problems with system setups.

Kernel drivers used by FFADO

Depending on the version and configuration of the kernel, FireWire devices are made accessible to FFADO either by the older three drivers ohci1394 + ieee1394 + raw1394 or by the newer two drivers firewire-ohci + firewire-core. The older set of drivers or the newer set or even both sets can be present in the kernel image itself (i.e. statically linked into it) or be installed as loadable modules. The latter is the normal and generally preferred way. The following text assumes that the drivers are loadable modules.

The task of ohci1394 and firewire-ohci is to operate the FireWire controller(s) in your PC. These can be PCI, PCI Express, CardBus, or ExpressCard controllers. The particular local bus does not matter to ohci1394 or firewire-ohci or FFADO at all. If you are using a FireWire CardBus or ExpressCard controller, be sure to put it in before proceeding, since most distros will only load the module when an appropriate device is present at boot or after it has been hot-plugged at runtime.

However, FFADO does not interact with ohci1394 or firewire-ohci directly. Rather, raw1394 maintains a device file /dev/raw1394 --- and firewire-core maintains several device files /dev/fw* --- through which FFADO communicates with the kernel.

ieee1394 acts as glue between ohci1394 and raw1394; you don't need to pay attention to ieee1394.

Before you can start any FFADO component --- e.g. jackd with its firewire driver, or the ffado-dbus-server, or ffado-test --- you must make sure that either * ohci1394 + ieee1394 + raw1394 are loaded and you have sufficient permissions to read and write /dev/raw1394, or * firewire-ohci + firewire-core are loaded and you have sufficient permissions to read and write the /dev/fw* that corresponds to the FireWire audio device.

From Linux kernel 2.6.37 onwards, only firewire-ohci + firewire-core are available.

Checking for the kernel modules

To check that the modules are in place, do

$ lsmod | grep -e 1394 -e firewire

You should see something like

raw1394                45184  16
dv1394                 38144  0
ohci1394               50868  9 dv1394
ieee1394              122216  3 raw1394,dv1394,ohci1394


firewire_ohci          30804  0 
firewire_core          42674  1 firewire_ohci

Side note: In kernel logs, lsmod output and so on, the dashes in module names like firewire-core are replaced by underscores. Keep this in mind when you are using grep and the likes.


$ grep -e 1394 -e firewire /proc/interrupts

checks whether ohci1394 or firewire-ohci is indeed bound to one or more FireWire controllers. If this is not the case, log in as root and try first

# modprobe firewire-ohci

and if this fails

# modprobe ohci1394

and repeat the checks from the beginning of this section.

If ohci1394 is present but lsmod did not show raw1394, you need to log in as root and do

# modprobe raw1394

Check out your distribution manuals and user forums to find out how to automate this.

Checking permissions of /dev/raw1394

This section is only applicable to setups which still use the older kernel drivers ohci1394 + ieee1394 + raw1394. Skip to the next section if you are using firewire-ohci + firewire-core.

Now you have to make sure that you (i.e. the user you're currently logged in as) has read and write access to the hardware. As is traditional in UNIX, a piece of hardware is represented as a virtual device file, with the usual file permissions:

$ ls -al /dev/raw1394

You should see something like

crw-rw---- 1 root video 171, 0 2008-10-21 00:50 /dev/raw1394

This tells you that the user root and members of the group "video" both can read and write. The name of the group can differ between distributions. As long as you are a member of that group, you're all set.

You can use the command

$ id

to find all groups you belong to:

uid=1000(youruser) gid=1000(users) groups=1000(users),1001(video)

If you don't have sufficient permissions, you can either add yourself to the group of your /dev/raw1394 node (video in this example) or change its group affiliation. In modern distributions, device permissions are set dynamically by the udev daemon. That means you need to change the corresponding udev rule; if you directly change the device node using chgrp and friends, your changes will be lost after the next boot. While the rules for udev are standard, usage appears to vary from one distro to another.The aim is to include the text :


in the right file in /etc/udev/rules.d, but the file name that we need to use will vary from one distro to another. There are three possible scenarios. Firstly, run the following command to find if a file with the needed rule already exists in the /etc/udev/rules.d folder:

$ grep -r raw1394 /etc/udev/rules.d 

If grep shows that the rule already exists in a file, for example /etc/udev/rules.d/50-udev-default.rules then you are all set, apart from possibly changing the name of the group that is specified. If no such rule is found, then check to see if a file called /etc/udev/rules.d/50-udev-default.rules already exists. If it does, append the text as shown above to the existing file. The third scenario is that 50-udev-default.rules does not exist in /etc/udev/rules.d. If this is the case, your distro is using a different directory for the default rules, and you must use a name other than 50-udev-default.rules to avoid overwriting all the default rules - it is suggested that you call this file /etc/udev/rules.d/50-raw1394.rules. Place the same text as above, (KERNEL=="raw1394*",GROUP="video",MODE="0660") into the new file.

In any of the above three cases, you might also wish to change the group specified in the rules file to one of which you are already a member, or you could make yourself a member of the currently set group. (The writers of the distro used in this example assumed that any interesting device on firewire has to be a DV camera, hence their choice of the 'video' group.)

Further information on udev configuration can be found in the udev manual page and possibly in /usr/share/doc/udev*/html/writing_udev_rules.html (online version).

After editing the udev rules, tell udevd to re-read them (as root):

# udevadm control --reload-rules

Note that if you chose to change your group membership, you will need to log out and back in to put the change in effect. If instead you changed the udev rule, you need to unload and reload the module (again as root):

# modprobe -r raw1394
# modprobe raw1394

(No need to reboot, though - this is ain't that other operating system :)

Checking permissions of /dev/fw*

This section is only applicable to the firewire-core kernel driver.

When your FireWire audio device is plugged in and properly powered up,

$ ls -l /dev/fw*

should show at least two files, e.g.

crw-rw---- 1 root root  254, 0 Apr 25 19:31 /dev/fw0
crw-rw---- 1 root video 254, 1 Apr 25 20:08 /dev/fw1


crw-rw---- 1 root root  254, 0 Apr 25 19:31 /dev/fw0
crw-rw---- 1 root audio 254, 1 Apr 25 20:08 /dev/fw1


crw-rw---- 1 root root  254, 0 Apr 25 19:31 /dev/fw0
crw-rw---- 1 root root  254, 1 Apr 25 20:08 /dev/fw1

Typically, but not necessarily, /dev/fw0 represents the "local node" i.e. the Linux PC itself, and /dev/fw1 represents the FireWire audio device. The more FireWire controllers are present in the PC and the more FireWire devices are plugged in, the more /dev/fw* files should show up. The precise numbering of these files depends on order of discovery by the kernel but is not actually interesting.

You can find out which file corresponds to what hardware by

$ grep . /sys/bus/firewire/devices/fw*/*_name

This should show something like

/sys/bus/firewire/devices/fw0/vendor_name:Linux Firewire

In this case, the user account which is going to run jackd etc. needs read and write permission to /dev/fw1 or whatever file was indicated by the last command. On the other hand, FFADO does not need permission to access any other /dev/fw* file, notably not to the ones that stand for the Linux PC itself.

File access permission can be granted via group ownership or via access control lists (ACLs). Which mechanism is used differs between Linux distributions. We will only discuss group ownership here.

If the ls output showed that the file of the audio device belongs to a non-root group like "video" or "audio", and

$ id

shows that your account is member of that group, you are set.

If this is not the case, download the following udev rules file:;a=blob_plain;f=debian/60-ffado.rules

As root user, copy this file into /etc/udev/rules.d/.

Then plug the audio device out and in again. After a few seconds, check ls -l /dev/fw* again. The corresponding file should now be owned by the "audio" group.

If the "audio" group does not exist on your system to begin with, the root user can create it by

# groupadd audio

If your user account is not yet member of the audio group, the root user can assign it by

# usermod -a -G audio youruser

If the audio device was assigned to the "video" group instead and your user is member of the video group, don't worry. This works just as well.

Further general FireWire troubleshooting

If you encounter problems with FireWire configuration that are not specifically issues with FFADO, feel free to ask for help on the general FireWire-on-Linux user mailinglist, linux1394-user:

Your posting should include a good description of your hardware and basic software environment (distribution), of the problem and of the diagnostics that you gathered so far.