Is there any plan to implement Class Compliant mode for the future ???

If RME would change there mind about enabling CC Mode for Digiface Dante, they would be the only Company with a portable Dante Solution for Linux on the Market. So Please... !

It should not be too much complicated from the macos driver.

I'm currently preparing for a multitrack recording session for which I will use the DigiFace Dante on a Mac Mini M1.

I would be so much happier if this interface had a Linux driver. OS X makes me sick.

I'm at the moment upgrading my MixBus versions on my Linux-based mixdown machine, boy this DAW has grown. The Linux box still uses a RME Digi 9652 from the golden days when there RME made Linux drivers. When the studio installation ever will go Dante, like the live setup did, It won't be the RME DigiFace then, unfortunately. Rather DigiGram then… so sad.

And it just got even better: https://forum.rme-audio.de/viewtopic.ph … 35#p239935

Hi Jeremy,

I believe you’re referring to my post on the LinuxAudio subreddit here:

I feel your pain.. I’ve been working to set up and use both a Digiface Dante and a UFX III under Linux. In my case, I need them to work with Reaper and PyAudio (Python). Since my reddit post, I have found a solution — not the ideal one, but will do for now and until RME solves the issue (hopefully soon), and happy to share:

Understanding Altsets
Both the Digiface Dante and UFX III offer three Alternative Settings (altsets) in Class Compliant mode.

For Digiface that is:

• Altset 1 → 32 channels I/O

• Altset 2 → 64 channels I/O

• Altset 3 → 128 channels I/O

For UFX III that is:

• Altset 1 → 34 channels I/O

• Altset 2 → 54 channels I/O

• Altset 3 → 94 channels I/O

You can check your card's altsets (and the "running" one) in the terminal:

• cat /proc/asound/cards
  This will list your sound cards. Identify your Digiface/UFX III’s card number (replace X below).

• watch cat /proc/asound/cardX/stream0
  This shows available altsets and which one is active.

The Problem
Altsets 2 and 3 do not work correctly under Linux. Altset 1 (lowest channel count) works reliably.
From my testing, this appears to be an RME Class Compliant firmware limitation, not a Linux or USB problem.

Solution: Forcing Altset 1
If you don’t explicitly select Altset 1, or you try to set up Reaper with channels that exceed altset 1, you’ll likely run into distortion, artifacts, or clocking issues cause Linux may choose the other altsets. Here’s how to ensure Altset 1 is used:

• In Reaper (ALSA)
  - Open Preferences > Audio > Device.
  - Select ALSA as the device type.
  - Set Input Channels and Output Channels to 32 (or whatever your Altset 1 max I/O is).
  → This forces ALSA to use Altset 1.

• For PyAudio or Direct ALSA Use
  - Create an ALSA configuration that explicitly sets:
  -- channels 32  (or whatever your /proc/asound/cardX/stream0.. says)
  -- format S32_LE (or whatever your /proc/asound/cardX/stream0.. says)
  I can share my config file next time I’m in the studio, but I recommend reading up on ALSA configuration basics first.
  

• For JACK
  - Configure JACK to match Altset 1’s I/O limits. This avoids mismatch problems and ensures clean audio.

PLEASE RME TEAM FIX THIS
While on the website https://rme-audio.de/fireface-ufx-3.html it clearly statea that ALL channels are available for Linux and in CC mode, right now, Linux can only access a fraction of the hardware’s full capability — specifically, Altset 1’s channel count.

I really hope I'm wrong about this and I'm just a newbie using Linux Audio incorrectly, but I did try a lot to find a solution, and also messaged RME support about it but got no response..

If 32/34 channels are enough for your needs, you can get stable, distortion-free audio with either Reaper, JACK, or PyAudio using Digiface/UFX III. For my needs unfortunately this is not enough, so, I hope RME will address this issue soon.

And I have no clue what there is to fix for us. If that information is correct then there seems to be a bug in Linux audio when handling Altsets other than 1. macOS prooves that all our Alternate Settings work in any combination/sample rate.

Thinking about it a simple explanation could be that you try to use a different Altset (means higher channel count) but the original AltSet is still active. Some kind of reset when changing might be missing. Or the change never happened, and channels are used that don't exist. Both would lead to high distortion as the buffer data is incorrect. And again these would be Linux (software) issues.

Are you on the latest DF Dante firmware 68 CC 20?

Hey everyone,

Absolutely agree! RME support has always been excellent in my experience. Sorry if I sounded critical earlier (this issue has been bugging me and my team for weeks). David, email on this subject was sent on Friday, June 7, 2025 at 10:40 PM BST (through my work email: dimitriosl@...).

On the topic:

That matches my experience (macOS works perfectly with my RME devices in CC mode) and your explanation makes sense. It’s unfortunate that Linux (which relies on CC mode) seems to struggle. If RME ever has the chance to test Digiface / UFX III on Linux directly, I’m sure you’d be able to pinpoint exactly the source of the problem.

That’s really interesting.. It seems like the same audio interfaces on the same Firmware version are being recognized differently.. maybe it’s a difference in Linux distributions? I’m on the latest Ubuntu (I saw you're on Debian?).

My guess here is that Linux might still be defaulting to the Altset with the highest channel count. Since our interfaces are being recognised differently, I would suggest you to the following test, and see how your PC reacts:

Proposed test:

1. Check for hardware-related issues (looks like you've done this):

• USB 3 used, plugged in a SuperSpeed USB port

• One way to confirm USB port speed is by typing lsusb -t in terminal

2. Check Device Settings:

• Set all your audio AD/DA devices and Digiface to 48kHz / 24-bit in Dante Controller
  (Feel free to choose your preferred settings, but I wouldn't go beyond 48kHz)

• I would also set my Audio Interface to be the Clock Learder

• Make sure all devices have adequate latency settings (I’d suggest 5ms+ for this testing just to rule out latency issues).

• Verify that your interface works is in CC mode and firmware is up-to-date

• On a Mac/PC with the Fireface USB/Totalmix installed, connect Digiface, open the Fireface app, and confirm all settings look correct: You should see "Apple CC" on the top right corner, firmware v9, Sample Rate 48kHz, MADI Format settings should also be correct (I would switch BNC I/O to Word Clock if you're not using MADI).

• If you updated the firmware, make sure you have rebooted your audio interface.
  

3. On your Linux machine:

• Temporarily disable all other audio servers (PulseAudio, JACK, Pipewire) so only ALSA is active. I believe you can do this by typing something like:

  systemctl --user stop pulseaudio.socket pulseaudio.service jackdbus jackd pipewire pipewire-pulse pipewire-media-session wireplumber

• Open a terminal and run:
  watch -d cat /proc/asound/card1/stream0
  This will update live as you playback/record through your Digiface—keep this terminal window active and visible.

4. Set up Reaper (you can use your DAW of choice but for me, Reaper is best for testing this):

• Open Reaper, go to Options > Settings, and set ALSA to 32 channels I/O.

• Set buffer size to something reasonable (e.g., 512), with block size 2 to 4

5. Now, the fun part: Observe Altset Behavior in terminal:

• While playing back or recording audio in Reaper, check the terminal window to see which Altset is active. This will probably be different for you, as your interface is being recognised differently.

• Then, try to change the Reaper settings to different channel counts that reflect your other altests, and check terminal to see if it follows that. If it does, it means Reaper is forcing a specific altset to be used -- that would align with my result.

• I'd love to know the findings of your test!

I have done the above myself, and setting the channel count to 32 in Reaper (or JACK for what it's worth) forces the card to use Altset 1; 64 channels uses Altset 2; 128 channels uses Altset 3. In my case, only Altset 1 (lowest channel count) works reliably for me. If I select any other value than the exact altset value, Linux seems to default to the highest channel count altset.

To conclude, it's pretty interesting to me that your audio interface's Altsets are different than mine. I'd like to see how your interface reacts to the above.

For reference, I'm pasting my  cat /proc/asound/card1/stream0 output here:

Every 2.0s: cat /proc/asound/card1/stream0                                                                                                          sooty: Mon Aug 11 10:31:55 2025

RME Digiface Dante (24243009) at usb-0000:04:00.1-3, super speed : USB Audio

Playback:
  Status: Stop
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 32
    Endpoint: 0x02 (2 OUT) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24
    Sync Endpoint: 0x82 (2 IN)
    Sync EP Interface: 1
    Sync EP Altset: 1
    Implicit Feedback Mode: No
  Interface 1
    Altset 2
    Format: S32_LE
    Channels: 64
    Endpoint: 0x02 (2 OUT) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24
    Sync Endpoint: 0x82 (2 IN)
    Sync EP Interface: 1
    Sync EP Altset: 2
    Implicit Feedback Mode: No
  Interface 1
    Altset 3
    Format: S32_LE
    Channels: 128
    Endpoint: 0x02 (2 OUT) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24
    Sync Endpoint: 0x82 (2 IN)
    Sync EP Interface: 1
    Sync EP Altset: 3
    Implicit Feedback Mode: No

Capture:
  Status: Stop
  Interface 2
    Altset 1
    Format: S32_LE
    Channels: 32
    Endpoint: 0x81 (1 IN) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24
  Interface 2
    Altset 2
    Format: S32_LE
    Channels: 64
    Endpoint: 0x81 (1 IN) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24
  Interface 2
    Altset 3
    Format: S32_LE
    Channels: 128
    Endpoint: 0x81 (1 IN) (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000
    Data packet interval: 125 us
    Bits: 24

When I perform the above test through Reaper, I get the following results:

# With Reaper setting to 32 channels I/O - sound comes out great:
Playback:
  Status: Running
    Interface = 1
    Altset = 1
    Packet Size = 1024
    Momentary freq = 48000 Hz (0x6.0001) ## Note this for later
    Feedback Format = 16.16                      ## Note this for later
Interface [...rest of the output]

# With setting to 64 channels - distorted sound
Playback:
  Status: Running
    Interface = 1
    Altset = 2
    Packet Size = 1024
    Momentary freq = 48000 Hz (0x6.0000) ## This changes to 0000
    ## Feedback Format IS MISSING completely from output
Interface...

# With setting to 128 channels - even slower/more distrorted sound
Playback:
  Status: Running
    Interface = 1
    Altset = 3
    Packet Size = 1024
    Momentary freq = 48000 Hz (0x6.0000) ## This changes to 0000
    ## Feedback Format IS AGAIN MISSING completely from output
Interface...

Cheers,
Dimitris