Esem/Eesn

I've had a Fireface UCX for over 10 years now. It's absolutely maxed, all inputs are busy, most outputs the same, ADAT, S/PDIF, BNC, MIDI, it's so deeply integrated into my studio, it's practically unthinkable that I should change it. And so it has been quite terrible that Apple, in their infinite wisdom, have decided to deprecate Firewire audio, and to push vendors into using a flawed DriverKit framework.

The problem

Generally speaking, DriverKit has a kernel part (provided by Apple) and a client part (provided by each vendor) that, taken together, handle audio. But there seem to be issues with the CPU scheduling of these components, and so DriverKit USB audio may stutter whenever a fast device ends up saturating i/o (relative to audio). On my Mac, there are audio dropouts, and RME's driver reports buffer underruns in its panel and in logs.

USB

Long story short, USB2's timing stability leaves a lot to be desired due to things like polling, and CPU dependency. It's probably fine for 2 or 4 channels, but my Fireface has 36 and they're all transferred all the time. I like this. If I had my way, audio would be synchronous, full-duplex, all the bandwidth all the time. Alas.

RME

For some reason, RME haven't convinced Apple to keep supporting the much more stable FireWire bus for DriverKit, or to schedule everything audio always on performance cores (or whatever it is they need to do for scheduling, I can't be bothered to know all the tech details anymore). So we're stuck with USB and crap DriverKit audio performance.

The Fix, For Now

Although Apple have deprecated Kernel Extensions, they haven't removed support for them, and as of macOS Sequoia and M4, kexts continue to work.

You'll need to relax SIP (System Integrity Protection). Obvs do this at your own risk.

With the disclaimer out of the way, here's what works on my Mac Studio M2 Max:

Firewire kext

Mac usb-c port 
  → Apple USB-C to Thunderbolt 2 adapter 
    → Apple TB2 to Firewire 800 adapter 
      → FW 800–400 cable 
        → RME Fireface UCX. 

Uninstall every other RME driver, and install the Fireface FireWire 3.41 or newer driver.

This setup may be unstable. It may work for you, depending on what software you have, your system load, restart habits, and other variables. I rarely turn off my Mac, instead letting it go to sleep, and switch between audio interfaces often. Sometimes the Fireface starts experiencing dropouts with Firewire, but it's hard to say why. More so, the USB kext sometimes does too.

USB kext

Mac usb-c port 
  → USB-C to USB-2 cable 
    → RME Fireface UCX. 

Uninstall every other RME driver, and install the Fireface USB Kernel Extension driver.

Notes

• In addition to SIP, macOS blocks the driver straight away, so before rebooting, navigate to System Settings, and allow the kernel extension to execute
• The safety buffer and offset are slightly larger with FireWire (as per UCX manual), equivalent to USB's "Normal" setting.
• Lastly, pick a USB-C port that isn't shared, e.g. with internal devices or other USB ports. On my mac, the back USB-A ports are shared with the front USB-C ports. This is important if you're going for USB kext. If you can, go for Firewire

(No) Support

Please don't email me with questions about your hardware. I've tried to put above what worked for me, after being on the RME forums for over a year, and banging my head against the wall with DriverKit, and then holding my nose and using USB audio until I ran out of patience and bought the silly dongles required.

Is macOS likely to remove support for kernel extensions? I think it's not there yet. Sonoma and Sequoia both continue to support them.

Performance

I am able to take Bitwig's buffer down to 32 samples - a low value I never need. RME and Apple components add another 56 or so samples to output latency (as reported by Bitwig), so effectively it's never below 96. I have settled on 128 samples buffer which is less than what I used with my old Hackintosh (2013). Do expect another 128 samples of total i/o buffer for macOS/driver alone (50-something for output alone). Find more specific timings in Dawbench and your RME manual.

Good luck!

P.S

With the odd dropouts using Firewire, eventually the audio subsystem got bogged down until no more audio came out of the RME interface. It did not need a restart, the interface did not need rebooting (good sign!), but I had to unplug all cables and adapters, quit Safari (which freed up 20GB RAM), then plug the cables and adapters back in.

If you need to diagnose coreaudio overload errors, I've found that this command does a decent job:

log show --predicate '(process == "coreaudiod") && (sender == "CoreAudio")' --last 60m

also this one:

log show --predicate '(sender == "IOAudioFamily")' --last 60m