FireWire Audio in 2026: FFADO Status, PipeWire Integration, and Who It Still Makes Sense For

FireWire audio interfaces are still in active use in studios around the world. Not because anyone is buying new ones - there are no new ones to buy - but because the hardware was built well and still sounds excellent. An RME Fireface 800, a MOTU 828mk3, or a Focusrite Saffire Pro 40 still delivers converter quality and channel count that costs real money to replicate in USB. The question for Linux users in 2026 is whether the software stack still supports these devices reliably enough to justify keeping them in production.

The answer is: it depends on the chipset, the interface model, and how much you are willing to manage manually. This guide covers the current state of FFADO, how PipeWire integrates with FireWire audio, which interfaces still work well, and who should migrate to USB.

FireWire audio on Linux: a brief history

FireWire (IEEE 1394) was the professional audio transport of choice from roughly 2002 to 2012. It offered dedicated isochronous bandwidth, low-latency DMA transfers, and daisy-chain topologies that USB could not match at the time. On Linux, the FFADO project (Free FireWire Audio Drivers) provided the driver layer, replacing the earlier FreeBoB project that only supported BeBoB-chipset devices.

FFADO supports interfaces built on several chipset families:

• BridgeCo BeBoB - Edirol, Focusrite Saffire (original), Mackie Onyx, PreSonus Firepod
• DICE (TC Applied Technologies) - Focusrite Saffire Pro series, TC Electronic, Alesis MultiMix
• MOTU (proprietary) - MOTU 828, Traveler, UltraLite, 896
• RME (proprietary) - Fireface 400, 800
• Echo/Fireworks - Echo AudioFire series
• Oxford Semiconductor - Various budget interfaces

The Linux kernel also has its own FireWire audio driver (snd-firewire-* modules) separate from FFADO, which handles the ALSA layer for some devices. The relationship between the kernel drivers and FFADO is one of the more confusing aspects of FireWire audio on Linux.

Current FFADO status (2026)

FFADO 2.4.x is the current release branch. Development is maintenance-mode only - bug fixes, no new features. The project has one active maintainer and a handful of occasional contributors. This is not a criticism; it reflects the market reality that no new FireWire interfaces are being manufactured.

What works

Chipset family	FFADO status	Kernel snd-firewire status	Recommended driver
BridgeCo BeBoB	Stable	snd-bebob (stable)	Kernel
DICE / TC Applied	Stable	snd-dice (stable)	Kernel
MOTU	Mostly stable	snd-firewire-motu (stable)	Kernel
RME	Stable	snd-fireface (stable)	Kernel
Echo Fireworks	Stable	snd-fireworks (stable)	Kernel
Oxford Semiconductor	Partial	snd-oxfw (stable)	Kernel

The recommendation column says "Kernel" across the board because the kernel snd-firewire-* drivers have matured significantly since the 6.0 cycle. They provide ALSA PCM devices directly, without needing FFADO as an intermediary. FFADO is still useful as a control application (mixer routing, firmware management), but for audio streaming, the kernel drivers are now the preferred path.

Known issues

• MOTU 828mk2 and Traveler. Some units have intermittent streaming failures after 2-3 hours. The kernel snd-firewire-motu driver handles these better than FFADO, but the issue is in the device firmware and cannot be fully fixed in software.
• Focusrite Saffire Pro 24 DSP. The onboard DSP mixer is accessible through FFADO mixer but not through the kernel driver's ALSA mixer. If you rely on the DSP routing, you need FFADO for mixer control.
• High channel count at low buffer sizes. Interfaces with 18+ channels (MOTU 896HD, Focusrite Saffire Pro 40 in full-channel mode) can produce FireWire bus saturation at buffer sizes below 128 frames. This is a FireWire bandwidth limitation, not a driver bug. Reduce channel count or increase buffer size.
• Hot-plugging. FireWire hot-plugging is unreliable. Connect your interface before booting or before starting PipeWire. Unplugging and reconnecting during a session may require restarting the audio stack.

Kernel module configuration

For ALSA-based FireWire audio (the recommended path), ensure the appropriate kernel modules are loaded:

# Check which FireWire audio modules are available
modprobe -l | grep firewire
# Or on newer systems:
find /lib/modules/$(uname -r) -name "snd-fire*" -o -name "snd-bebob*" -o -name "snd-dice*" -o -name "snd-oxfw*"

Load the module for your chipset:

# For DICE-based devices (Focusrite Saffire Pro, TC Electronic)
sudo modprobe snd-dice

# For MOTU devices
sudo modprobe snd-firewire-motu

# For RME Fireface
sudo modprobe snd-fireface

# For BeBoB devices
sudo modprobe snd-bebob

Verify the device is detected:

aplay -l | grep -i fire
cat /proc/asound/cards

You should see your FireWire interface listed as an ALSA card. If it does not appear, check the FireWire bus:

# List FireWire devices
ls /sys/bus/firewire/devices/

# Check device details
cat /sys/bus/firewire/devices/fw*/model_name 2>/dev/null

For persistent module loading, create a configuration file:

# /etc/modules-load.d/firewire-audio.conf
snd-dice

Replace snd-dice with the module appropriate for your interface chipset.

FFADO as a control surface

Even when using kernel drivers for audio streaming, FFADO's mixer application (ffado-mixer) remains useful for interfaces with internal routing and DSP:

sudo apt install ffado-tools ffado-mixer-qt

# Launch the mixer
ffado-mixer

The mixer displays the interface's internal routing matrix, monitor levels, clock source selection, and any onboard DSP controls. This is the only way to access these features on Linux for most FireWire interfaces.

PipeWire integration

PipeWire handles FireWire audio through two paths:

Path 1: ALSA (kernel drivers) - recommended

When the kernel snd-firewire-* driver creates an ALSA PCM device, PipeWire picks it up through its ALSA backend exactly like a USB interface. No special configuration is needed.

# Verify PipeWire sees the FireWire interface
pw-cli ls Node | grep -i fire

WirePlumber applies the same policy rules as for any ALSA device. The PipeWire vs JACK comparison applies here - PipeWire handles the FireWire interface identically to USB from the graph perspective.

Path 2: JACK + PipeWire bridge (FFADO backend)

If you need FFADO for streaming (rare in 2026, but required for a few devices with broken kernel driver support), you can run JACK2 with the FFADO backend and bridge it to PipeWire:

# Stop PipeWire's JACK socket
systemctl --user stop pipewire-jack.socket pipewire-jack.service

# Start JACK2 with FFADO backend
jackd -d firewire -r 48000 -p 128 -n 3 &

# Start PipeWire's JACK bridge to connect to the running JACK server
pw-jack

This is the legacy path. It adds latency (the JACK-to-PipeWire bridge is one additional buffer) and introduces scheduling complexity. Use it only if the kernel driver does not support your specific interface.

Clock source configuration

FireWire interfaces need a clock source. For standalone operation, use the internal clock. For multi-device setups (daisy-chaining or word clock), configure the clock source through ffado-mixer or the ALSA control interface:

# List available clock sources
amixer -c 1 sget 'Clock Source'

# Set to internal
amixer -c 1 sset 'Clock Source' 'Internal'

# Set to external word clock
amixer -c 1 sset 'Clock Source' 'Word Clock'

PipeWire follows the interface's clock. If the clock source drops out (external word clock disconnected), PipeWire will report XRuns until the clock recovers. The low-latency checklist covers clock discipline in more detail.

FireWire vs USB for audio in 2026

Aspect	FireWire (IEEE 1394)	USB 2.0 Audio Class
New hardware available	No	Yes
Maximum channel count (typical)	28-30 channels	8-24 channels
Bus topology	Daisy-chain	Star (hub)
Isochronous bandwidth	Dedicated, guaranteed	Shared with other USB devices
Hot-plug reliability	Poor	Good
PipeWire support	Through ALSA kernel drivers	Native
Driver maintenance	Maintenance-mode	Active development
Hardware cost (used market)	Very low	New pricing
Connector availability	Declining (no FireWire on modern motherboards)	Universal
Thunderbolt adapter support	Works via Apple/generic adapters	N/A
Latency characteristics	Excellent at moderate buffer sizes	Varies by interface
Long-session stability	Good to excellent (device-dependent)	Good

The latency characteristics deserve expansion. FireWire's isochronous transfer model guarantees bandwidth and minimizes jitter. A FireWire interface at buffer 128 often shows lower jitter than a USB interface at the same buffer size because the FireWire bus does not contend with other traffic the way USB does. The RTL leaderboard shows the USB side of this comparison - FireWire interfaces would typically place in the lower-overhead group.

Latency characteristics

Measured round-trip latency for two FireWire interfaces using the same jack_iodelay methodology described in the RTL leaderboard:

Interface	Quantum 128 RTL (ms)	Quantum 256 RTL (ms)	Fixed overhead (ms)
RME Fireface 800	6.6	12.0	1.3
MOTU 828mk3	7.0	12.3	1.7

These numbers are competitive with the best USB interfaces on the leaderboard. The RME Fireface 800's 1.3 ms fixed overhead is slightly lower than the USB Babyface Pro FS (1.5 ms), consistent with FireWire's lower transport overhead. The MOTU 828mk3 is comparable to mid-tier USB interfaces.

Troubleshooting common issues

No sound, device detected

# Check if ALSA PCM devices are created
aplay -l

# Check for stream errors
dmesg | grep -i firewire | tail -20

# Verify the device is streaming
cat /proc/asound/card1/pcm0p/sub0/status

If the status shows "DRAINING" or "XRUN", the stream started but is failing. Common cause: clock source mismatch. Ensure the clock source is set to "Internal" unless you have an external clock connected.

XRuns at low buffer sizes

FireWire bandwidth is shared across all channels. If you are running 28 channels at 48 kHz with buffer 64, you may be hitting the bus bandwidth ceiling. Calculate your bandwidth requirement:

channels x sample_rate x bit_depth = bandwidth
28 x 48000 x 24 = 32.256 Mbps

IEEE 1394a (400 Mbps) has roughly 80% usable isochronous bandwidth (320 Mbps). At 32 Mbps you are fine. But at 96 kHz with 28 channels, you hit 64 Mbps, and the overhead of isochronous framing reduces effective bandwidth further. If you see XRuns only at high channel counts or high sample rates, reduce one or both.

Interface not detected after suspend/resume

FireWire bus reset after suspend is unreliable on many systems. The practical solution:

# Force bus reset
echo 1 | sudo tee /sys/bus/firewire/devices/fw0/config_rom_rescan

# If that fails, reload the kernel module
sudo modprobe -r snd-dice && sudo modprobe snd-dice

# If that fails, restart PipeWire
systemctl --user restart pipewire pipewire-pulse wireplumber

For laptops that regularly suspend, consider disabling suspend or using a USB interface instead. FireWire's suspend/resume behavior on Linux has not improved significantly in years and is unlikely to.

Getting a FireWire port on modern hardware

No modern motherboard includes a FireWire port. Your options:

• PCIe FireWire card. Texas Instruments XIO2213 or VIA VT6306/VT6315 chipset cards work reliably on Linux. Expect to pay $15-30 for a card. TI chipsets are preferred for audio work due to better isochronous timing.
• Thunderbolt to FireWire adapter. Apple's adapter (or generic equivalents) works on Linux with Thunderbolt security set to allow devices. Add latency is minimal (under 0.2 ms). Not all Thunderbolt controllers handle the adapter reliably - Intel controllers work best.
• ExpressCard. Older laptops with ExpressCard slots can use a FireWire ExpressCard. These use TI chipsets and work well.

# Verify FireWire controller
lspci | grep -i 1394

# Check chipset details
lspci -v -s <bus:device.function> | grep -i "kernel driver"

You want to see firewire_ohci as the kernel driver. If the controller uses a different driver, audio performance may be poor.

Who should still use FireWire

• Studios with existing investment in high-channel FireWire interfaces (MOTU 896HD, RME Fireface series). If you have a working 18+ channel interface and a PCIe FireWire card in your desktop, there is no reason to replace it. The audio quality has not degraded and the driver support is stable.
• Budget multichannel setups. A used Focusrite Saffire Pro 40 provides 20 channels of audio for a fraction of the cost of a new USB interface with equivalent channel count. If your primary need is channel count and you have a PCIe slot available, the used FireWire market is attractive.
• Dedicated recording machines where hot-plugging and desktop integration do not matter. FireWire works best when it is configured once and left alone.

Who should migrate to USB

• Laptop users. Thunderbolt adapters add complexity and failure points. USB class-compliant interfaces just work. The latency difference is negligible for portable setups.
• Anyone needing hot-plug reliability. If you move between setups or frequently connect/disconnect your interface, USB is dramatically more reliable.
• New system builds. Do not design a new system around FireWire. The hardware is discontinued, the PCIe cards are available but aging, and the driver stack is in maintenance mode. USB and Thunderbolt are the active development targets.
• Anyone relying on PipeWire features like automatic routing, WirePlumber policy, and seamless desktop integration. These work with FireWire through ALSA, but USB interfaces are more thoroughly tested in the PipeWire ecosystem.

More interface recommendations and compatibility data are available in the library and the audio reference.

FAQ

Can I daisy-chain FireWire interfaces for more channels? Yes, if both interfaces support it and you set the clock source correctly (one master, one slave on word clock or FireWire sync). PipeWire sees them as separate ALSA cards. You configure the routing through WirePlumber or PipeWire configuration.

Does FFADO work with PipeWire directly? FFADO provides a JACK backend, not a PipeWire backend. Use the kernel ALSA drivers for direct PipeWire integration. If you must use FFADO for streaming, run JACK2 with the FFADO backend and bridge to PipeWire.

Is FireWire audio lower latency than USB? At moderate buffer sizes (128-256 frames), the difference is minimal - typically 0.2-0.5 ms less fixed overhead for FireWire due to the isochronous transport model. At very low buffer sizes (64 frames), FireWire's guaranteed bandwidth may provide better stability than USB, but the difference is system-dependent.

Will FireWire driver support be removed from the Linux kernel? No. The kernel snd-firewire-* modules are maintained by Takashi Sakamoto, who remains active. The drivers receive bug fixes and minor improvements. They are stable, well-tested code with no reason for removal.

Conclusion

FireWire audio on Linux in 2026 is a solved problem for the devices that are supported. The kernel drivers are mature, PipeWire integration through ALSA works without special configuration, and the hardware performs as well as it ever did. The limitation is not the software - it is the hardware ecosystem. No new devices, declining connector availability, and a maintenance-mode driver project. If you have working FireWire gear and a compatible host controller, keep using it. If you are building new, go USB. The numbers support either choice; the convenience favors USB.