RME Fireface 400 and TC Konnekt Live: Are they supported by the FFADO drivers?

If you're not running Pipewire this shouldn't be too difficult to sort out.

So you installed FFADO added

blacklist snd-fireface

to your blacklist.conf and rebuilt your initramfs and when you reboot you no longer see the devices in ALSA or Pulseaudio. Correct?

A quick way to see if the interface is being seen by the system is to run

ffado-test ListDevices

Let me know the output of that.

If you are running PipeWire we will need to tackle things differently. 

Posted by: @vennmints

↑

So you installed FFADO added

blacklist snd-fireface

to your blacklist.conf and rebuilt your initramfs and when you reboot you no longer see the devices in ALSA or Pulseaudio. Correct?

Correct, I did exactly that and just did it once again.

The output of

ffado-test ListDevices

is for both devices:

=== 1394 PORT 0 ===
  Node id  GUID                  VendorId     ModelId   Vendor - Model
   0       0x0001660408c0050d  0x00000166  0x00000023   TC Electronic - KonnektLive
no message buffer overruns

=== 1394 PORT 0 ===
  Node id  GUID                  VendorId     ModelId   Vendor - Model
   0       0x000a350109cd353e  0x00000A35  0x00101800   RME - Fireface 400
no message buffer overruns

And yes, Pop!_OS uses PipeWire by default. I already tried stopping/killing the service, but it just automatically restarts, and removing the packages also doesn't work because of some dependencies.

Thanks for pointing me into the PipeWire direction. I copied /usr/share/pipewire/pipewire.conf to /etc/pipewire/pipewire.conf and added

    {   name = libpipewire-module-ffado-driver
    args = {
        #driver.mode       = duplex
        ffado.devices     = [ "hw:KonnektLive" ]
        #ffado.period-size = 1024
        #ffado.period-num  = 3
        #ffado.sample-rate = 48000
        #ffado.slave-mode  = false
        #ffado.snoop-mode  = false
        #ffado.verbose     = 0
        #latency.internal.input  = 0
        #latency.internal.output = 0
        #audio.position    = [ FL FR ]
        source.props = {
            # extra sink properties
        }
        sink.props = {
            # extra sink properties
        }
    }
    flags = [ ifexists nofail ]
    
}

in the section

context.modules = [

This makes the TC Konnekt device visible in all Pipewire related applications such as Gnome Settings and also QJackCtl. Even all the channels are labelled correctly, nice!

Unfortunately there is no sound going through the interface, PipeWire uses up to 60% CPU, Settings and QJackCtl are crashing constantly. Something's obviously off here.

After a fresh restart, PipeWire reports this, and it looks good:

$ systemctl --user status pipewire
● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2024-01-20 12:54:40 CET; 20s ago
TriggeredBy: ● pipewire.socket
   Main PID: 7983 (pipewire)
      Tasks: 14 (limit: 18736)
     Memory: 13.8M
        CPU: 38.907s
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service
             └─7983 /usr/bin/pipewire

Jan 20 12:54:40 pop-os pipewire[7983]: 00471527971:  (dice_avdevice.cpp)[ 833] showDevice:      fabrik reverb R
Jan 20 12:54:40 pop-os pipewire[7983]: 00471527976:  (dice_avdevice.cpp)[ 833] showDevice:      adat 1 | optical L
Jan 20 12:54:40 pop-os pipewire[7983]: 00471527978:  (dice_avdevice.cpp)[ 833] showDevice:      adat 2 | optical R
Jan 20 12:54:40 pop-os pipewire[7983]: 00471527983:  (dice_avdevice.cpp)[ 833] showDevice:      adat 3
Jan 20 12:54:40 pop-os pipewire[7983]: 00471527985:  (dice_avdevice.cpp)[ 833] showDevice:      adat 4
Jan 20 12:54:40 pop-os pipewire[7983]: 00471527990:  (dice_avdevice.cpp)[ 833] showDevice:      adat 5
Jan 20 12:54:40 pop-os pipewire[7983]: 00471527992:  (dice_avdevice.cpp)[ 833] showDevice:      adat 6
Jan 20 12:54:40 pop-os pipewire[7983]: 00471527997:  (dice_avdevice.cpp)[ 833] showDevice:      adat 7 | coaxial L
Jan 20 12:54:40 pop-os pipewire[7983]: 00471527999:  (dice_avdevice.cpp)[ 833] showDevice:      adat 8 | coaxial R
Jan 20 12:54:40 pop-os pipewire[7983]: 00471557729:  (dice_avdevice.cpp)[ 324] setSamplingFrequency: Setting sample rate: 48000

After trying to play audio, this happens:

$ systemctl --user status pipewire
● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; vendor preset: enabled)
     Active: deactivating (stop-sigterm) since Sat 2024-01-20 12:57:37 CET; 5s ago
TriggeredBy: ● pipewire.socket
   Main PID: 7983 (pipewire)
      Tasks: 14 (limit: 18736)
     Memory: 26.1M
        CPU: 3min 31.069s
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service
             └─7983 /usr/bin/pipewire

Jan 20 12:55:34 pop-os pipewire[7983]: spa.mixer-dsp: 0x580e59de45a8: out of buffers (1)
Jan 20 12:55:34 pop-os pipewire[7983]: spa.mixer-dsp: 0x580e59de45a8: out of buffers (1)
Jan 20 12:55:34 pop-os pipewire[7983]: spa.mixer-dsp: 0x580e59de45a8: out of buffers (1)
Jan 20 12:55:34 pop-os pipewire[7983]: spa.mixer-dsp: 0x580e59de45a8: out of buffers (1)
Jan 20 12:55:34 pop-os pipewire[7983]: spa.mixer-dsp: 0x580e59de45a8: out of buffers (1)
Jan 20 12:55:34 pop-os pipewire[7983]: spa.mixer-dsp: 0x580e59de45a8: out of buffers (1)
Jan 20 12:55:34 pop-os pipewire[7983]: spa.mixer-dsp: 0x580e59de45a8: out of buffers (1)
Jan 20 12:55:34 pop-os pipewire[7983]: spa.mixer-dsp: 0x580e59de45a8: out of buffers (1)
Jan 20 12:56:58 pop-os pipewire[7983]: mod.ffado-driver: FFADO xrun

At this point

systemctl --user restart wireplumber pipewire pipewire-pulse

does not even work anymore, and I have to restart the whole system in order to get sound back.

Getting the FFADO drivers working with PipeWire should be straightforward.

Create a file called 10-ffado.conf in ~/.config/pipewire/pipewire.conf.d/ and populate it with the example from here.

https://docs.pipewire.org/page_module_ffado_driver.html

Then restart pipewire or reboot. Both will work.

That said, FireWire + PipeWire doesn't appear to be the best experience from the feedback I have received.

I will be testing it out myself in the upcoming weeks. 

Thanks so much for helping me out! Unfortunately, this does not really work on my system.

- The card doesn't show up in Setup of QjackCtl, when "firewire" Driver is selected

- It sometimes shows up in Coppwr as FFADO SOURCE and FFADO SINK

- When I select it in Gnome settings, a Youtube video that played fine through the internal speakers is producing not sound through Konnekt Live and Video stutters

- Laptop fans spin up and down constantly, indicating high CPU load.

- running systemctl --user status pipewire shows this:

● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2024-01-22 10:11:40 CET; 37s ago
TriggeredBy: ● pipewire.socket
   Main PID: 2043 (pipewire)
      Tasks: 13 (limit: 18736)
     Memory: 26.5M
        CPU: 8.010s
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service
             └─2043 /usr/bin/pipewire

Jan 22 10:12:11 pop-os pipewire[2043]: spa.mixer-dsp: 0x5eded5565da8: out of buffers (1)
Jan 22 10:12:11 pop-os pipewire[2043]: spa.mixer-dsp: 0x5eded556b408: out of buffers (1)
Jan 22 10:12:11 pop-os pipewire[2043]: spa.mixer-dsp: 0x5eded5601618: out of buffers (1)
Jan 22 10:12:11 pop-os pipewire[2043]: spa.mixer-dsp: 0x5eded551b288: out of buffers (1)
Jan 22 10:12:11 pop-os pipewire[2043]: spa.mixer-dsp: 0x5eded551f758: out of buffers (1)
Jan 22 10:12:11 pop-os pipewire[2043]: spa.mixer-dsp: 0x5eded5523c28: out of buffers (1)
Jan 22 10:12:11 pop-os pipewire[2043]: spa.mixer-dsp: 0x5eded55280f8: out of buffers (1)
Jan 22 10:12:11 pop-os pipewire[2043]: spa.mixer-dsp: 0x5eded552c5c8: out of buffers (1)
Jan 22 10:12:11 pop-os pipewire[2043]: spa.mixer-dsp: 0x5eded5531c28: out of buffers (1)
Jan 22 10:12:11 pop-os pipewire[2043]: spa.mixer-dsp: 0x5eded550b278: out of buffers (1)

I'm looking forward to seeing the results of your tests! I would be curious to know how one could remove PipeWire from the system, in order to improve things.

For now I'll just go with my 133ms latency. I figured how to offset that in Reaper, so at least I can record (with hardware monitoring) and stuff is nicely in sync.

Had a moment this afternoon to try PipeWire on Debian Testing. This is it running with the FFADO drivers.

Seems you can skip the blacklisting and 10-ffado.conf if you have jackd2 installed along with pipewire-jack and libffado.

Noticed a 2ms reduction in round-trip latency using the FFADO drivers. 16ms vs 19ms at 128/3/48K. 

When using FFADO with QjackCtl your interface will not show up. The only option you should have is default, select that.

Also, FFADO drivers are for connecting to Jack aware applications like DAWs. Not useful for general desktop apps.

With Pulseaudio/Jack you can use pulseaudio-module-jack to bridge the connection but the only thing I can find for PipeWire is module-jackdbus-detect and it's not having any of it.

Really spent a day playing with FFADO.

Verdict: Don't bother, not even a little bit. Stick with the ALSA drivers when using PipeWire.

If you really want to try them switch them drop the following in ~/.config/pipewire/pipewire.conf.d/ffadogobrr.conf

context.modules = [
{ name = libpipewire-module-ffado-driver
args = {
#driver.mode = duplex
#ffado.devices = [ "hw:0" ]
#ffado.period-size = 1024
#ffado.period-num = 3
#ffado.sample-rate = 48000
#ffado.slave-mode = false
#ffado.snoop-mode = false
#ffado.verbose = 0
#latency.internal.input = 0
#latency.internal.output = 0
#audio.position = [ FL FR ]
source.props = {
# extra sink properties
}
sink.props = {
# extra sink properties
}
}
}
]

Configure your settings and restart pipewire.

Tried it with a couple of different interfaces and none would pass audio with Jack or pw-jack. It's also spectacularly crashy.

FWIW Pipewire does not replace jack, pulseaudio or even ALSA. It is a layer of abstraction and control on top of the mess that those 3 are. So it greatly simplifies setting inputs and outputs in new and exotic ways.

So is no surprise if you have a working Jack config already that pipewire will just work on top of that too.

Where I find the most benefit is in being able to create dummy sinks and sources and using them to route through different programs. So a clean mic input can go to a Browser video call at the same time a re-routed mic source can be piped through a voice changer app and also go to the same Browser session. You can then enable or disable the re-route and switch from normal voice to vocoder voice without needing intermediate hardware to do that for you.

That is just an example obviously anything is really possible from merging two audio streams into 1 or piping an audio stream to a real time transcription service. You get the drift.

tldr;

If you are already set up for sound already, pipewire should be just a drop in replacement for the way you managed that set up.

@veritanuda pipewire has its own version of the JACK libraries https://man.archlinux.org/man/pw-jack.1

In this case pw-jack explodes into a ball of nope so real jack must be used along with the pipewire-jack package.

Then we run into issues with module-jackdbus-detect taking down the system when using the FFADO drivers when attempting to bridge that connection.

Oh no! I'm sorry to hear about your troubles. I also read a couple of similar stories now on r/pop_os. The verdict seems to be to either deal with the latency that ALSA-Firewire imposes or switch to a USB or PCI audio-interface in the long run. Because removing Pipewire from Pop!_OS does not seem to be straightforward.

Maybe Pipewire will work better with FFADO in the future, but I absolutely can't judge the likeliness of this.

The latest update to PipeWire 1.0.4 has the bits needed to make FFADO work. At least that's the claim.

I still need to test it myself.

Hey, that's really awesome! I'm hyped to test it out myself, currently still waiting for the official PipeWire update from my distro.

Also, frankly it's fantastic to see that my intense testing and reporting here lead to an improvement in PipeWire - I would never have imagined that happening.