You are not logged in. Please login or register.
RME User Forum → Linux → Digiface Dante + Linux?
Can anyone tell me if the Digiface Dante will work in Class Compliant mode under Linux and if so, what the limitations might be?
The Digiface Dante does not support Class Compliant mode.
Is there any plan to implement Class Compliant mode for the future ???
No, sorry.
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... !
I fully agree!!!
That's a pity!!!
It should not be too much complicated from the macos driver.
Making drivers for Linux is as easy as turning water into wine for a skilled person. RME has all the necessary know-how for that driver issue. I'm not sure about the wine.
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.
Digiface now supports Class Compliant (CC) mode. You just need to update to latest firmware and check the "CC mode" box. This will convert the Digiface Dante to CC Mode. Note: If you want to deactivate CC mode you can do so by re-installing the firmware and unticking the box.
And it just got even better: https://forum.rme-audio.de/viewtopic.ph … 35#p239935
Hi guys, Hi Matthias 
I've been struggling for the past week or more with all this (meaning UFX III or Digiface Dante in CC Mode AND sound / music with linux). I was hoping for a huge relief reading this topic about new fw / new cc versions, thinking there might be the solution for me here...
The story is quite simple. I am preparing a kit based on RME for a live show with immersive sound. There's an artist coming to play for this show. The guy's running Bitwig studio v3.3 on a Debian 12 os. He's apparently never played a show like this, he is used to bring his Steinberg interface with him for his shows, sends a Stereo and everything works fine this way.
So basically, this time he needs / we need a lot of separate outputs to go to the console for the immersive aspect, and me and a few colleagues were in charge of designing the tech solution to do that. Having done this many times in the past, we immediately thought RME with MADI or Dante channels to the console, which can do both.
And basically, so far, we never got things to work properly. We tried with the same Debian and Bitwig version than our guy, same Kernel, updated real-time version of the Kernel, we tried with updated versions of Bitwig, we tried Reaper, we tried Ardour, we tried using Jack2 or Alsa drivers, ... nothing comes right out of our cards when we run Linux. All the ins and outs of the cards are available in every DAW we tried, so we can actually set up seperate outputs as usual but this is the only thing that works fine.
To better explain what we're talking about here, let's say we set up like 16 audio tracks in a DAW, on which we insert pure 1000Hz test tones (oh what fun ). Now imagine putting a bitcrusher plugin set up on 6 bits or any heavy sound-alterating setting on every single channel we previsouly set up : that is what we're hearing.
I read someone who wrote about a very "distorted" sound with his UFX, I think he has the same phenomenon that we do, we hear it more like a digital alteration rather than a distorsion but we never heard our 1KHz tones right.
And now we feel that we have done everything we can, and wonder where's this coming from. I would say the CC mode works fine when it comes to accessing the interfaces's I/O ressources, but only this.
What do you guys think we should look into ? Could it be hardware related on our PCs (I'm thinking USB bus / chipsets incompatibility) ? Does it just not work ?
Fun thing is we did manage to hear a 1000Hz coming out right of our RMEs : using Audacity, for a single stéréo output, using neither jack, or alsa...
Last thing would be setting up a Mac or a PC with Win10 but let's say we're up for the Linux challenge... Does any of you think of something reading this ... ?
Thanks, and thanks for this great knowledge base too !
Jeremy
Hi Jeremy,
I believe you’re referring to my post on the LinuxAudio subreddit here:
“I read someone who wrote about a very ‘distorted’ sound with his UFX.”
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.
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..
I'm afraid I can't find any mail from you or on the topic at hand.
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.
Hi guys,
Well... first of all, thanks for your answers. Being kind of new to the Linux environnement, I'm sorry but I had ot rely on the community
And I surely didn't want to spark any debate on wether it's a Linux or a RME issue... I'm no developper but I tried the same thing with my Mac even before I wrote my first post, so I had a feeling this was more of a Linux thing... But anyways. It's great for someone like me to have users AND RME staff addressing this So thanks a lot.
Now, diving into the technical shenanigans... The Reaper thing was just a test, this is not what we'll be using live.
I tried Bitwig first cause it's the guy's DAW, then I thought "maybe it's a Bitwig thing, let's try Reaper".
I checked the altsets like you advised, using the terminal. This is what I got (I'm trying the Digiface Dante, which is even better for us if we get it to work):
0 [sofhdadsp ]: sof-hda-dsp - sof-hda-dsp
LENOVO-21H2S6YF00-ThinkPadL14Gen4
1 [Dante24207227 ]: USB-Audio - Digiface Dante (24207227)
RME Digiface Dante (24207227) at usb-0000:00:14.0-1, super speed
So thats card 1 for me, then :
RME Digiface Dante (24207227) at usb-0000:00:14.0-1, super speed : USB Audio
Playback:
Status: Stop
Interface 1
Altset 1
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: 0x81 (1 IN)
Sync EP Interface: 2
Sync EP Altset: 1
Implicit Feedback Mode: Yes
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: 0x81 (1 IN)
Sync EP Interface: 2
Sync EP Altset: 2
Implicit Feedback Mode: Yes
Interface 1
Altset 3
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: 0x81 (1 IN)
Sync EP Interface: 2
Sync EP Altset: 3
Implicit Feedback Mode: Yes
Capture:
Status: Stop
Interface 2
Altset 1
Altset 3 is the one with 32 channels, not alt1. Honestly, 32 channels is great for me. Now I have a question about this : what's exactly this issue here ? Is it about the number of channels to be handled, meaning there's a difficulty in handling more than 32 channels ? Or is it about the altset id not being handled above altset1 by the system ... ?
My very first test with bitwig was to try to have a simple stereo coming out, so two channels only. It didn't work with only two channels...
I'm looking how to tell Jack to handle 32 channels max.
Thanks again for your preicous help, this is a challenging subject and I love it !!!!
Cheers
Are you on the latest DF Dante firmware 68 CC 20?
Hi Matthias,
Yep... ! Updated yesterday...
Also, I found how to setup Jack for 32 channels right after I wrote my last post... Still doesn't work ! although I can see the Bitwig audio setup following all the changes I make in the Jack setup... Output routing in Jack works fine too, but the sound is still a digital mess...
Hey everyone,
jesav wrote:
It's great for someone like me to have users AND RME staff addressing this. So thanks a lot.
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:
"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."
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.
"Altset 3 is the one with 32 channels, not alt1."
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 very first test with bitwig was to try to have a simple stereo coming out, so two channels only. It didn't work with only two channels.."
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: 24When 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
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@...).
Sorry, nothing in my inbox (only one mail from you from September 2024). Which address did this go to?
Hi Matthias,
Yep... ! Updated yesterday...
That explains that. The latest firmware has different alternate settings than all firmwares before, which started with 32 channels. See here: https://forum.rme-audio.de/viewtopic.ph … 35#p239935
The new CC channel order wasn't mentioned but is part of the whole scheme to work better over sample rate ranges.
You could try the previous firmware to check if that one behaves better on Linux:
https://www.rme-audio.de/downloads/fut_ … ac_342.zip
Also, I found how to setup Jack for 32 channels right after I wrote my last post... Still doesn't work !
At least one issue solved 
Hi Jeremy,
I believe you’re referring to my post on the LinuxAudio subreddit here:
“I read someone who wrote about a very ‘distorted’ sound with his UFX.”
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.
I just thought I'd follow up on this: I was considering purchasing a UFXIII for higher channel count in CC mode in Linux, but have hesitations here, as I need 42 channels at 96k. Did you ever get this sorted out? I am wondering if I should consider the Madiface XT II instead, since altset 1 seems to support 54 channels on that interface. It would be an expensive change, since I would need another set of converters, but at least it is an option.
I just thought I'd follow up on this: I was considering purchasing a UFXIII for higher channel count in CC mode in Linux, but have hesitations here, as I need 42 channels at 96k. Did you ever get this sorted out? I am wondering if I should consider the Madiface XT II instead, since altset 1 seems to support 54 channels on that interface. It would be an expensive change, since I would need another set of converters, but at least it is an option.
Hello,
Unfortunately I didn't find a way around this.
What seems to be consistent between different RME devices I tried is, the altset with the least number of channels seems to be working as expected, while the other altsets introduce the issues decribed.
E.g. Choosing 32 channels for Digiface Dante in Reaper forces altset 3 (in a previous firmware version it was altset 1). Choosing 34 channels for RME UFX III forces the altset that limits channels to 34.
If RME MADIfaceXT II's altset with the lowest channel count is at 42 channels, it could work. I am not sure about 96kHz though as I've only tested 44.1 and 48kHz.
Please let me know if you test it out.
Best,
Dimitris
gaw0319 wrote:I just thought I'd follow up on this: I was considering purchasing a UFXIII for higher channel count in CC mode in Linux, but have hesitations here, as I need 42 channels at 96k. Did you ever get this sorted out? I am wondering if I should consider the Madiface XT II instead, since altset 1 seems to support 54 channels on that interface. It would be an expensive change, since I would need another set of converters, but at least it is an option.
Hello,
Unfortunately I didn't find a way around this.
What seems to be consistent between different RME devices I tried is, the altset with the least number of channels seems to be working as expected, while the other altsets introduce the issues decribed.
E.g. Choosing 32 channels for Digiface Dante in Reaper forces altset 3 (in a previous firmware version it was altset 1). Choosing 34 channels for RME UFX III forces the altset that limits channels to 34.
If RME MADIfaceXT II's altset with the lowest channel count is at 42 channels, it could work. I am not sure about 96kHz though as I've only tested 44.1 and 48kHz.
Please let me know if you test it out.
Best,
Dimitris
This is unfortunate to hear- I wonder if someone from RME could comment on if they have any ideas for why this is happening. I wonder if it would be possible to simply have a version of the firmware which only has one altset, the max channel count. I do not know a lot of the under-the-hood technical coding stuff for audio interfaces, but why have separate altsets/channel modes anyway? Why not just have the max-channel-count mode the one and only altset/mode? What is the purpose of the lower count altsets? I suppose it is likely to do with different sample rates restricting channel counts, but I wonder if there is another way to go about it which prevents this issue from occurring.
Yes, I can possibly test this out, but would require me to upgrade to a Madiface, which would also require that I get an additional set of converters, which would be unfortunately expensive. According to this post https://forum.rme-audio.de/viewtopic.php?id=41751 it looks like this user managed to get 52 ins/54 outs working on his Madiface XT II, which confirms the theory: RME interfaces in Linux only work properly using the altset with the lowest channel count. I am not sure if this is solely a Linux issue, or perhaps an issue with just Linux + RME specifically, since I have not seen this issue on other interfaces, and if the Madiface XT II is working fine with 52 channels, it is not a 32-channel count limitation either.
I know us Linux audio folks are a small subset, but Linux use does seem to be rapidly growing- A recent Steam survey showed the OS at something like 7% userbase of English speakers, at least of Steam users. With Valve recently announcing that they're making the Steam Machine prebuilt Linux PCs at a price and time where budget prebuilts are going to be in high demand due to parts costs (and with the slow decline of quality and increasing bloat of Windows with each version), Linux will only get more popular with time, and will likely not decline in popularity. No audio interface manufacturer has really dedicated to Linux support yet, but that means if someone does do so, they'd have an effective monopoly on that emerging and growing Linux userbase.
Hello all
The problem described by jimmygian above is an issue with the descriptor parsing for SuperSpeed devices needing to send more than 1024 bytes per transfer interval. This is a linux side problem which RME cannot fix. A patch by Dylan Robinson has been submitted to the kernel and merged to the release candidate for the 6.19 kernel due early Feb. I've done some initial testing with linux-6.19-rc2 and my UFX3 and am able to call all 3 altsets by defining the appropriate channel counts in Reaper. 96K projects playback correctly with altset 2 (54 channels) , 192k plays back correctly with altset 1 (34 channels) and all 96 channels appear to be there for altset 3 at 48k. I don't own any other madi gear yet so I haven't tested all 96 channels. I also haven't tested with pipewire yet, and to my understanding this would require the latest git version of pipewire and possibly the wireplumber latest git to resolve the separate pulseaudio 64 channel limit issue. The 64 channel limit has been repoted as solved on the Motu 16A and this should work for our RME devices too. I'll try and do some more testing soon. Hope this information answers some of your questions gaw0319. The fix is on the horizon and things are looking good.
Hello all
The problem described by jimmygian above is an issue with the descriptor parsing for SuperSpeed devices needing to send more than 1024 bytes per transfer interval. This is a linux side problem which RME cannot fix. A patch by Dylan Robinson has been submitted to the kernel and merged to the release candidate for the 6.19 kernel due early Feb. I've done some initial testing with linux-6.19-rc2 and my UFX3 and am able to call all 3 altsets by defining the appropriate channel counts in Reaper. 96K projects playback correctly with altset 2 (54 channels) , 192k plays back correctly with altset 1 (34 channels) and all 96 channels appear to be there for altset 3 at 48k. I don't own any other madi gear yet so I haven't tested all 96 channels. I also haven't tested with pipewire yet, and to my understanding this would require the latest git version of pipewire and possibly the wireplumber latest git to resolve the separate pulseaudio 64 channel limit issue. The 64 channel limit has been repoted as solved on the Motu 16A and this should work for our RME devices too. I'll try and do some more testing soon. Hope this information answers some of your questions gaw0319. The fix is on the horizon and things are looking good.
This is very good news, thank you for the update there! While usability, gaming, user-friendliness, etc, has gotten a lot better on Linux in recent years, pro audio still does feel occasionally fragmented and DIY, so I'm glad to hear they're addressing this finally. I do like Pipewire and use Reaper via Jack (into Pipewire) right now, but I have no qualms about using ALSA instead since I rarely ever need multi-client abilities when doing audio work. I'm using the Liquorix kernel at the moment, but they seem to be pretty good about keeping up to date with latest kernel releases as well.
I'll keep an eye out for that kernel release- It's good timing anyway, since I was thinking of upgrading my UFX+ to a Madiface XT II anyway (I'm expanding my console's channel count, so would need the future expandability anyway), which may take a bit of time to tear my rack apart and redo everything in there. Been just doing some research on choosing the right converters in the meantime!
Hello all
The problem described by jimmygian above is an issue with the descriptor parsing for SuperSpeed devices needing to send more than 1024 bytes per transfer interval. This is a linux side problem which RME cannot fix. A patch by Dylan Robinson has been submitted to the kernel and merged to the release candidate for the 6.19 kernel due early Feb. I've done some initial testing with linux-6.19-rc2 and my UFX3 and am able to call all 3 altsets by defining the appropriate channel counts in Reaper. 96K projects playback correctly with altset 2 (54 channels) , 192k plays back correctly with altset 1 (34 channels) and all 96 channels appear to be there for altset 3 at 48k. I don't own any other madi gear yet so I haven't tested all 96 channels. I also haven't tested with pipewire yet, and to my understanding this would require the latest git version of pipewire and possibly the wireplumber latest git to resolve the separate pulseaudio 64 channel limit issue. The 64 channel limit has been repoted as solved on the Motu 16A and this should work for our RME devices too. I'll try and do some more testing soon. Hope this information answers some of your questions gaw0319. The fix is on the horizon and things are looking good.
Tested with Linux v6.19-rc5; rendered audio on all three Altsets (higher than 32 channels) produces the same timing.
Well done!
The problem described by jimmygian above is an issue with the descriptor parsing for SuperSpeed devices needing to send more than 1024 bytes per transfer interval. This is a linux side problem which RME cannot fix.
I can confirm this. On USB 2 Linux uses High Bandwidth mode to send more than 1024 Bytes. With USB 3 this kind of 'workaround' is not needed (obviously), but it seems exactly that is happening there as well. So depending on the number of channels (aka amount of data) it works or distorts.
Nice to see there is a fix available now.
RME User Forum → Linux → Digiface Dante + Linux?
Powered by PunBB, supported by Informer Technologies, Inc.