There are many reasons to buy and trust RME but Linux is not one of them, now I quote verbatim the UCX II user manual on page 96 about Class Compliant Mode, chapter 31:

... so the CC Mode it is not for Linux support, it's just a fluke and IMHO the word 'Linux' has been included in the RME website and its user manual for marketing reasons.

As an UCX II User I can't recommend it for use under Linux, too expensive to lose the Driver/TotalMix/Computer support.

Has anyone used UFX III in CC Mode on Linux and can comment on the experience?

But I don't think you get 24 ins/outs in USB-2 (UFX II). Or do you? Then this would be a great alternative. I think I need USB-3 to get 8 (12) analog and 16 ADAT.

We have a project upcoming in autumn which requires 24 inputs/outputs, that's why I'm eager to verify that the UFX III would be an option (as opposed to UCX II which I would otherwise favour).

Total in and out 60 https://rme-audio.de/fireface-ufx-ii.html

Oops posted at the same time lol

Ah ok you do need confirmation of someone in the know, so not me. But it would be highly expected if the UFX3 has it.

Excellent, thank you!

Using Tumbleweed and the UFXIII

With USB3 you hit the 64 channel limit imposed by Pulse which is carried into pipewire-pulse.  I had a quick look at the pipewire code but simply changing the channel count wasn't enough, it needs a proper review by the pipewire team, I notice someone else has requested an increase to this limit on the pipewire site.

Removing pipewire-pulse, you  hit the same limit in wireplumber.  It's suggested (by perplexity.ai) that this is configurable but nothing I've changed has worked. Maybe someone knows the truth of configuration...

Removing pipewire and going back to ALSA,  all 94 channels are present but I could not get the settings right, I had constant distortion at 44.1, 48 and 96.  I tried various combinations of jack (using qjackctl) but I could not resolve the issue, which I believe might be something to do with the format.  Has anyone else got this working? I would be happy going back to ALSA/jack until pipewire catches up.

Using usb2 (which removes MADI and thus reduces the channel count) works fine with pipewire and I have had much success with Mixbus10, and Mixxx. However I am unable to work beyond 48k, I get lots of errors if I try to use 96k, no matter what quantum is used.  This is odd as my babyface pro works fine at 96k. I wonder if this is something to do with usb2/3 ?

I'd be most interested to hear what others have manage to get working.

# System Details Report
---

## Report details
- **Date generated:**                              2025-04-04 09:59:44

## Hardware Information:
- **Hardware Model:**                              Gigabyte Technology Co., Ltd. B650M AORUS ELITE AX
- **Memory:**                                      64.0 GiB
- **Processor:**                                   AMD Ryzen™ 9 7900 × 24
- **Graphics:**                                    AMD Radeon™ Graphics
- **Disk Capacity:**                               17.0 TB

## Software Information:
- **Firmware Version:**                            FB3f
- **OS Name:**                                     openSUSE Tumbleweed
- **OS Build:**                                    (null)
- **OS Type:**                                     64-bit
- **GNOME Version:**                               48
- **Windowing System:**                            Wayland
- **Kernel Version:**                              Linux 6.14.0-1-default

Further notes: 28/10/25

Pipewire has now increased the limit to 128, you will still get warnings about the 64 channel pulse limit but if you are not using pulse then it can be ignored.

Unfortunately the problem is beyond the pipewire remit, it seems to be something within alsa. By setting up an alsa node with 34,54, or 94 channels you can get the appropriate altmode (on usb3) However only 34 channels is distortion free. What's also unfortunate is that pipewire is card centric, not node centric, so setting up alsa nodes makes no difference, pipewire always sees 94 channels and can make use of user defined nodes.

So an appeal to alsa developers, why the distortion with high channel counts? Is this beyond alsa, is it more to do with xhci?

My quick USB-2 downgrade was to try on an old Raspberry Pi 3B I had lying around – here the interface comes up, as expected, with 30 channels, and playback via Jack is clean. The channels seem to be 12 analog + 2 aes/ebu + 16 ADAT, at least according to the onboard meter view. For my current project this would be ok, so I will have to understand how to downgrade the laptop from USB3 to USB2, perhaps just with a dumb USB-hub inbetween?

Another interesting bit is that jack by default uses 32-bit mode, or you have (in QJackCtl) the option to use 16-bit. On my colleague's Mac laptop however, the audio midi setup shows different configurations that are all 24-bit. Might this be the issue, and there is a way to force Jack to run in 24-bit integer?

By the way, on the USB3 machine, when stopping Jack and yielding back to pulse, the way to get the sound "undistorted", is to switch from "Configuration: Multichannel" to "Configuration: Pro Audio" and back to "Multichannel". No idea what those are, but that suggests that there is some change in the driver configuration that puts the machine back into the right state.

On the device, that's only for driver operation, but for CC mode, you have to stay in CC mode. But a quick solution is actually to grab a USB 2 cable instead, LOL, that works immediately at 30 channel mode, no distortion in Jack/ALSA. So at least for now, I have a working solution, ultimately would be great to know what the Jack/ALSA issue is in USB-3 mode, in order to leverage the MADI.

Apart from the embarassing channel count limitations: I wouldn't rule out the laptop's USB subsystem to cause the USB-3 issues. Even Intel had issues to support isochronous data streams with more than a handful channels at one point in time. You should try all three USB-A ports, and also the Thunderbolt port (includes USB 3 with 10 GB/s, so different path/chip).