Using more than one FFADO device on the same bus

The basics

Using more then one device with ffado (and freebob!) is actually pretty easy: Just daisy-chain them all on one bus and ffado will use all (recognized) devices as one big device. Nothing special to do, no cryptic command-line arguments.

The problems with such a multi-device setup are the same as everywhere where digital devices exchange audio-streams: The word-clocks have to be synced so all devices produce the same amount of samples per channel per time-unit. The ways of syncing depend on the devices in use. Some devices can sync to incoming S/PDIF, ADAT or AES signals, some devices have dedicated word-clock i/o-connectors. Firewire also provides two intrinsic ways to sync, there can be a dedicated clock signal and the isochronous transfer also includes a global clock. It depends on the devices which sync-mechanisms are provided and work.

Of course all devices have to run at the same sampling-rate for this to work.

Practical results

Some results and tips from practical experience:

Arnold Krille

[State as of 2009/10/02]

Since having two devices (an "reported to work" Presonus Firepod and an soon-to-be-fully-supported Focusrite Saffire PRO24) I did some playing around with the sync. Note: I constantly drive my devices at 48kHz so different sampling rate are not a show-stopper for me.

Several scenarios work rather well here:

  • Firepod and Saffire on the same firewire bus both synced "internal" seems to sync both to the firewire-clock. Which works stable.
  • Firepod and Saffire on the same bus and a s/pdif connection from the Firepod to the Saffire. When the Saffire is set to sync to "s/pdif" you can watch the sync light appear, dis-appear and re-appear again when starting jackd. Then it runs stable.
  • Saffire connected to the laptop, Firepod connected to the big pc with a s/pdif connection between the devices also works for synchronization.

One time I even had my internal SoundBlaster? Live! send s/pdif-clock to the Firepod forwarding the s/pdif-clock to the Saffire...

Sometimes the sync doesn't stabilize fast enough before jackd/ffado bails out, maybe an option to increase the tolerances has to be added somewhere. Sometimes when jackd/ffado crashes, it leaves the host-controller in a strange state where all subsequent streaming fails. Only a reboot of the pc helps in that case, both bus resets (ffado-test BusReset) and re-powering the devices don't help.

[Update 2009/11/13] Running both devices synced via spdif with 3x128 I measured some round-trips with jdelay. Going spdif from the firepod to the saffire I get 10.6ms delay and going analog from the saffire to the firepod I get 12.1ms, all pretty stable values. It looks as if the DA/AD-conversion takes around 1.5 in these devices combined...

Jörn Nettingsmeier

Jörn Nettingsmeier has tried to combine a Saffire Pro 26 (with ADATs disabled, effectively turning it into a 10in/10out device) and a Mackie Onyx 16 channel mixer with firewire option (an 18in/2out device). It didn't work ("could not run Driver Cycle..").

Taking into account Arnold's explanations about synchronisation, it seems that those devices are *not* able to sync themselves to the Firewire clock and that the failure is due to clock drift. Since the Mackie has neither S/PDIF I/O nor wordclock, there is no way to ensure synchronisation in this case.

Bandwidth Considerations

Stefan Richter (s5r6 on IRC) has some wisdom to share concerning the bandwidth usage, i.e. whether it is theoretically feasible to squeeze a given number of channels through the wire:

[18:19:56] <s5r6_> nettings: regarding this: "how many channels can one hope to pipe through a single firewire, anyways? this would have been 8 + 18 ins and 8 + 2 outs, at 48k, 1024/3."
[18:20:15] <nettings> s5r6_: yes?
[18:20:35] <s5r6_> nettings: bandwidth requirement should be staright-forward to determine if you know the stream formats
[18:20:59] <s5r6_> nettings: another issue is available DMA contexts on the OHCI controller
[18:21:21] <s5r6_> nettings: here I'm not sure how audio channels translate to DMA contexts
[18:21:55] <s5r6_> nettings: most controllers implement 4 iso receive contexts + 8 iso transmit contexts
[18:22:22] <s5r6_> nettings: Agere controllers offer 8 + 8; I think few other controllers 4 + 4
[18:24:35] <s5r6_> nettings: for each FireWire bus channel to receive or to transmit on, 1 DMA context is necessary (except in multi-channel receive mode, but ffado doesn't use this), but still, a FireWire channel may or may not contain more than one audio channel
[18:37:37] <s5r6_> nettings: I found a presentation slide about IEC 61883-6 (ex mLAN) which shows that 256 audio or MIDI streams can be wrapped into IEEE 1394's maximum of 64 bus channels --- i.e. 4:1.
[18:37:45]  s5r6_ should get himself the spec
[18:41:12] <nettings> s5r6 should commit this wisdom to the wiki, since netting's mind is volatile :)
[18:41:28] <nettings> s5r6_: i'm starting a wiki page, willing to chime in?
[18:42:33] <s5r6_> nettings: sure

The Focusrite Answerbase seems to limit the number of audio channels to something between 80 and 96 (if the numbers in their name are about the number of channels).

The FAQ has additional info.