• nuri
  • ADAT user
  • Offline
  • Registered: 2016-04-20
  • Posts: 23

Topic: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

For a few days, I read here that the Digiface USB is now supported by the Linux kernel 6.12. Nice!
I own a Digiface USB paired to 2 A/D-D/A converters Behringer ADA8200 over optical ADAT.

Yesterday I compared the roundtrip latency performance of the Digiface USB on 2 different systems.

On one side, a Tuxedo Laptop with AMD Ryzen 7 8845HS processor with following software specs:
- latest Linux Tuxedo OS (based on Ubuntu 24.04)
- Liquorix kernel version 6.14
- Reaper 7.33 (Linux native version)
- Reaper project with 176 tracks and 82 FX (only ReaVST and JSFX), no VST instrument, only *.wav items
- Reaper audio settings: 128 samples, 24 bit, 48 kHz, Digiface controlled over ALSA backend (no Jack)

On the other side, a Mac mini 2024 with M4 Apple processor (10 cores, 16 GB RAM, 256 GB SSD, the cheapest one for 650 €) with following software specs:
- MacOS Sequoia (latest upgrade in december last year, since always offline)
- RME stock USB driver for the Digiface USB
- Reaper 7.33 (Apple Mac arm version)
- same Reaper project as above
- Reaper audio settings: 32 samples, 24 bit, 48 kHz using the RME driver for Digiface USB
- RME TotalMix set on DAW mode (everything on default)

On both systems, the audio settings are clean and usable (they produce no audible glitches, some xruns are popping sometimes out, they are reported by Reaper but they are rare and not audible).
On Linux, I can not set the buffer under 128 samples otherwise Reaper is not able to play anything.
On MacOS I can set the buffer as low as 15 samples (true!!!) and Reaper is always able to play - almost -  glitchfree the audio.

The available CPU power on both systems is almost the same. Here a short comparison:
https://www.cpubenchmark.net/compare/59 … M4-10-Core

On the Linux system, I measured a round-trip latency of 4,9 ms.
On the Mac system, I measured a round-trip latency of 0,6 ms.
(no, there is no typo. It is 0,6 ms. Zero point six milliseconds = 600 microseconds)


Here is the measuring method I used:

track in Reaper playing 1 sample impulse wav file --> Operating system --> RME Digiface USB --> audio output through ADA8200 --> electric voltage through XLR/XLR cable --> audio input through ADA8200 --> RME Digiface USB --> Operating system --> track in Reaper recording the incoming impulse

In the end, I measured in Reaper the time between the played impulse and the recorded impulse and I got the numbers from above.
The "RT longest-block" in Reaper's performance meter shows 2,67 ms in Linux and 0,67 ms in MacOS.

How can I get 0,6 ms roundtrip latency with MacOS?!?
The Behringer ADA8200 is sold with a processing latency of about 0,55 ms for one A/D or D/A conversion, according to this web site:
https://www.soundonsound.com/reviews/be … n-ada-8200

The Apple system performs 8x faster than the Linux system with the same Digiface USB and the same Reaper project.
Can these results be confirmed by some people here?

What is the quality point here? The RME driver or Apple core audio or both?

2 Reply by vinark (edited by vinark 2025-05-14 13:59:21)

  • vinark
  • DAW Mastermind
  • Offline
  • Registered: 2009-06-05
  • Posts: 3,177

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

On mac the latency is compensated by reaper since there is a known buffer size. The 0.6 delay you see is from the converters I guess. You could try an adat loopback recording. That should if everything is correct in core audio be near 0ms. It looks like on linux you see the real roundtrip without compensation.

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
BFpro fs, 2X HDSP9652 ADI-8AE, 2X HDSP9632
  • nuri
  • ADAT user
  • Offline
  • Registered: 2016-04-20
  • Posts: 23

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

@ vinark

mmm... Ok but the buffer size is also known on Linux. Not compensated?
I have to admit that the MacOS system is really pleasant to play music since I can not feel any latency.
I'm playing bass guitar and processing my signal over it and get my monitor over in-ear.

And what about this:
"The "RT longest-block" in Reaper's performance meter shows 2,67 ms in Linux and 0,67 ms in MacOS."
???

That would confirm that the Apple system is way faster than the Linux one. Am I missing something logically or technically?

In my measuring method, there is one D/A and one A/D conversion. It means I should at least measure a latency of 2 x 0,55 = 1,1 ms, if everything I read about the ADA8200 is right...
I bought the ADA8200 at the end of 2024. Maybe they received faster converters. The article of soundonsound.com claiming they have a latency of 0,55 is from 2013.

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

On Linux, I can not set the buffer under 128 samples otherwise Reaper is not able to play anything.
On MacOS I can set the buffer as low as 15 samples (true!!!) and Reaper is always able to play - almost -  glitchfree the audio.
...
On the Linux system, I measured a round-trip latency of 4,9 ms.
On the Mac system, I measured a round-trip latency of 0,6 ms.

What is the quality point here?

Its not a quality point, its how you measure.
Basically, you compare a 16 (Mac) with 128 (Linux) sample buffer here. Thats the main reason for the differences.

Maybe some physical background:
48 kHt = 48000Hz = 48000 Samples per second = 48 samples per millisecond.
So, a theoretically ideal system would report at least:
16 samples at 48kHz = 0.3ms
128 samples at 48kHz = 2.7ms


As vinark said. Reaper seems to do some Latency compensation. Probably different on Macs and Linuxes. I am not familiar with reaper, but it seems this is not a "real" RTL measurement and not comparable at all.
A real measurement would be to involve the physical stuff only, without any compensation by DAWs, sw, etc.
Basic scheme:
OUT Signal (Impulse Play) -> USB Cable -> Interface(s) -> Processing on Interface(s) -> USB Cable -> IN Signal (Impulse Rec)

You can use the RTL Utility (available for Mac, Win and Linux) for accurate measurements:
https://oblique-audio.com/rtl-utility.php

“Do It For Her”
My Gear: Bontempi Magic light Keyboard

5 Reply by nuri (edited by nuri 2025-05-15 10:28:46)

  • nuri
  • ADAT user
  • Offline
  • Registered: 2016-04-20
  • Posts: 23

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

@ maggie33

Thanks for the link! I didn't know this tool. I will try it.

Correction: I'm comparing a 32 bit (Mac) with 128 bit (Linux) buffer size.

I can manually add in Reaper a latency compensation but I have not done this. Neither in Mac nor in Linux.

I think if a compensation occurs, then through the RME driver, not directly in Reaper.

EDIT:
I now think that a compensation occurs directly in Reaper in both systems.

6 Reply by nuri (edited by nuri 2025-05-15 10:18:39)

  • nuri
  • ADAT user
  • Offline
  • Registered: 2016-04-20
  • Posts: 23

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

I made the round-trip latency measurements with the RTL Utility.


On Linux:

in the RTL Utility, if I choose the ALSA backend, I get a big dropdown list to choose from. Looks like this:
https://i.postimg.cc/WqFMDp6J/Linux-ALSA-Dropdown.png



If I select any entry related to "Digiface USB", I get the error message "Error when trying to open audio device!"
"Das Argument ist ungültig".
https://i.postimg.cc/PPv4Jy2F/Linux-ALSA-error.png



If I select the Jack backend with 48 kHz and 32 samples, I get the error message "Buffer under/overrun detected, Audio is glichting, try changing the buffer size".
https://i.postimg.cc/5XcmCzr9/Linux-Jack-32spl.png



If I select the Jack backend with 48 kHz and 128 samples, the RTL Utility can make the measurement and reports 13,833 ms.
https://i.postimg.cc/SXk7Zhqw/Linux-Jack-128spl.png



On MacOS:

Much easier, no backend to choose! I only set the input and output to "Digiface USB" and clicked on "Measure RTL".

With 48 kHz and 128 samples, I get 6,833 ms measured latency.
https://i.postimg.cc/236TRrvY/Mac-128spl.png



With 48 kHz and 32 samples, I get 2,833 ms measured latency.
https://i.postimg.cc/kVsNzpgD/Mac-32spl.png



Soooo... For me as end user, it means:

- the fastest I can run the Linux system is 13,833 ms RTL.
- the fastest I can run the Mac system is 2,833 ms RTL.

13,833 / 2,833 = 4,9

The Mac system is 4,9 times faster than the Linux one and that's what concerns me as end user who wants to make music.

And this is the reason why I bought the Mac Mini M4.

I do everything with linux except real-time audio processing.
I'm struggling for 15 years now...

7 Reply by nuri (edited by nuri 2025-05-15 17:07:17)

  • nuri
  • ADAT user
  • Offline
  • Registered: 2016-04-20
  • Posts: 23

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Correction:

in the Mac system, I can even run at 15 samples buffer size.
(not 16 but 15 samples is the smallest buffer size I can set).

It means that the RTL of the Mac system could even be shorter than 2,833 ms.


All the reported measurements here confirm what I'm feeling as musician when playing over these different systems.
There's no noticeable latency when I play through the Mac.


Why is the Linux system not able to play with a buffer size under 128 samples?

  • vinark
  • DAW Mastermind
  • Offline
  • Registered: 2009-06-05
  • Posts: 3,177

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

You could install a fresh win 10 on the linux computer on an usb stick and run the RTL utility with asio driver. That way you know how capable the laptop is and what might be possible under linux if somehow the driver would improve.

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
BFpro fs, 2X HDSP9652 ADI-8AE, 2X HDSP9632
  • nuri
  • ADAT user
  • Offline
  • Registered: 2016-04-20
  • Posts: 23

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

@ vinark

lol!!!

Yes I could do this with Windows but... no, don't want it.
I'm struggling for 15 years with Linux and real time audio processing. I can now wait 2 years more that things improve. Or 5 years more, or 10 years more...
In the meantime, I have the Mac mini that is a total "no brainer" and not expensive to make music.
But seriously, I don't like MacOS. I use it exclusively for Reaper and real time audio.

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Again, you are comparing "apples with pears" here.
- jack is always an additional on top SW Layer. This will always add latency.
- you use XQuartz to control RTL Utility on your Linux. (why?)

To be able to make a "useful" comparison:
- configure alsa correctly
- Linux (always) uses CC-Mode - use CC-Mode on your Mac, too
- Use same Sample Buffers on both systems (however)

Anyhow, you will always compare:
- a M4 with a AMD CPU
- a system with drivers vs a system without drivers
-> this makes no real sense (in my mind)

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • nuri
  • ADAT user
  • Offline
  • Registered: 2016-04-20
  • Posts: 23

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

@ maggie33

I agree on the fact that the comparison is not totally fair but:

In the meantime, I have the Mac mini that is a total "no brainer" and not expensive to make music.
In the meantime, I have the Mac mini that is a total "no brainer" and not expensive to make music.
In the meantime, I have the Mac mini that is a total "NO BRAINER" and not expensive to make music.
In the meantime, I have the Mac mini that is a total "NO BRAINER" and not expensive to make music.
"NO BRAINER"
"NO BRAINER"
"NO BRAINER"


Indeed, thank you very much for the link to the RTL Utility. It's also a no brainer that does the job quick and well.

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Everybody understands what you want to say with this.
No need to repeat/cry out different variants.

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • nuri
  • ADAT user
  • Offline
  • Registered: 2016-04-20
  • Posts: 23

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

@ maggie33

I quote you and answer directly in your text:

Again, you are comparing "apples with pears" here.
True. The point is that I'm one more time disappointed that I can not make music with Linux. My posts are written from an end user point of view who doesn't care about the whole technical stuff behind the fact that the Mac mini (600 €) does the job and the much more expensive - but really good - Linux Laptop (1.500 €) not.
- jack is always an additional on top SW Layer. This will always add latency.
I'm not sure. Jack is from the beginning designed for real time audio. Some Linux people claiming Jack adds latency, other people saying not.
- you use XQuartz to control RTL Utility on your Linux. (why?)
Hu?!? The MacOS screenshots are made on... MacOS and the Linux screenshots are made on... Linux (Tuxedo OS with KDE Plasma). I downloaded the RTL Utility for Mac and for Linux and ran it on the respective OS. I don't really understand what you're talking about.

To be able to make a "useful" comparison:
- configure alsa correctly
Yeah, how?!? I don't want to drown in an orgy of Linux configuration and waste two weeks only to realize that my efforts have been in vain.
- Linux (always) uses CC-Mode - use CC-Mode on your Mac, too
False. It depends on how the driver is implemented.
- Use same Sample Buffers on both systems (however)
I made it for the 128 samples buffer size. Look above. Measured RTL:
- on Mac: 6,833 ms
- on Linux: 13,833 ms
What's really anoying, is that Linux is not able to play anything below 128 samples. 13,833 ms is the fastest I can achieve.

Anyhow, you will always compare:
- a M4 with a AMD CPU
And?!? Should I compare a M4 with a M4 or a Pentium with a Pentium?
The AMD Ryzen 7 8845HS is a really powerful CPU. Look at the benchmark link I've posted in my first message.
The M4 is better in the single thread rating and needs half the electrical power (22 W against 45 W) than the AMD. But when it comes to pure processing power, the 8845HS holds up well.
- a system with drivers vs a system without drivers
Sorry, I don't get it. "Digiface USB now supported in Linux kernel 6.12" means that a driver had been written.
Both systems are "with driver" but the Linux one is not written by RME.
-> this makes no real sense (in my mind)
Because you are not looking at this comparison from the point of view of an end user (musician), but - I assume - from the point of view of a frustrated Linux nerd, which I can understand, because I was one too :-)

  • vinark
  • DAW Mastermind
  • Offline
  • Registered: 2009-06-05
  • Posts: 3,177

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Well now the point of your post is unclear. Is it simple Mac is better for low latency then Linux? Then yes we agree, Mac and windows are more suited for audio then Linux.
Cheers!

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
BFpro fs, 2X HDSP9652 ADI-8AE, 2X HDSP9632

15 Reply by Hopslost (edited by Hopslost 2025-11-16 19:35:37)

  • From: Germany
  • Registered: 2025-02-06
  • Posts: 34

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

For decades there is more music around than we can listen to in a lifetime and producing the next track with AI is a click away. So the metric is not about how easy/cheap it is to make music in the first place. Everybody can do it. It is generic.
A great piece of art can be technically complicated or very simple (and tend to be the latter).
Your music may be produced more efficiently with proprietary solutions, but you are investing your free time, your creativity and make yourself more dependent on an ecosystem that gradually takes away your freedom.

Just saying, that the standing as an artist, your projection is on a whole different level if you make the tools used, as much as possible, your own. If nobody cares for your work of art, at least you know you own the tools to remake and improve it. With proprietary solutions there are always looming monthly fees, advertising, spying etc. That's why we need alternatives.

UCX II, BBF Pro FS, Quadmic II, PCIe HDSPe Multiface II, AIO Pro
  • nuri
  • ADAT user
  • Offline
  • Registered: 2016-04-20
  • Posts: 23

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

@ Hopslost

As already written in this thread, I do EVERYTHING related to computer in my life with Linux (since 2007) except real time audio.
I regularly check here in the RME forum if things are improving. And yes, they do, but not for my case (I'm using the combination Mac+Digiface+ADA8200+Reaper+ReaVST+TukanJSFX as a mixing console with 32 inputs and 32 ouputs).

I read the topic "RME Digiface USB support now in kernel 6.12", by bassblank.

I thought: "nice, I give Linux audio another try!" (since I already own a Digiface USB)

I tried it out and published the results here.

Everyone can then interpret and use these results as they see fit.

As for me, I've come to my own conclusion and I'm still patiently waiting to free myself from proprietary solutions for real-time audio signal processing.

And I'd like to thank maggie33 one last time for pointing out a better way of measuring latency, as my initial protocol was not the right one. I had simply noticed a big discrepancy between THIS Mac system and THIS Linux system and now I have quantified measurements that seem quite plausible.

  • vinark
  • DAW Mastermind
  • Offline
  • Registered: 2009-06-05
  • Posts: 3,177

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Ah most of the times people ask questions here, so that was the confusion.

Vincent, Amsterdam
https://soundcloud.com/thesecretworld
BFpro fs, 2X HDSP9652 ADI-8AE, 2X HDSP9632
  • Registered: 2023-06-30
  • Posts: 422

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

nuri wrote:

I read the topic "RME Digiface USB support now in kernel 6.12", by bassblank.

Looks like me and you have different definitions of support. There is no support for Linux from RME at this point. Period. Use it at your own risk, there is no support, no warranty, no liability.

As for me, I've come to my own conclusion and I'm still patiently waiting to free myself from proprietary solutions for real-time audio signal processing.

What makes you think that RME products are not a proprietary solution? BTW, the so-called "free" and "open source" solutions are also almost always proprietary: they are not in public domain and copyrighted and licensed. Exceptions are very rare.

Fireface UCX II + ARC USB > ADI-2 Pro FS R BE > Neumann KH 750 DSP + MA 1 > KH 120 A

19 Reply by maggie33 (edited by maggie33 2025-05-17 04:55:59)

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Guys, please – we’ve already had plenty of fundamental discussions about whether Mac, Linux, or Windows is “better.”

It was never my intention to drift into personal evaluations of operating systems or processors.
The goal – at least from my side – has always been to learn from each other and share experience.

@nuri: Thanks for your direct responses. Apologies if mine came across as personal – that wasn’t my intention.
I actually agree with you: the M4 Mac Mini is excellent in terms of price/performance. RTL times with RME drivers from around 3ms are well-known on Silicon Macs…
I also use a Mac myself – but Linux and Windows too – and honestly, I’m quite neutral when it comes to operating systems.
However, I did think along the same lines as vinark: it initially seemed like you were aiming for a neutral comparison. And asked for help/tipps/suggestions what could cause such huge RTL differences...
That’s actually what made this discussion interesting for me – because you own the Digiface USB, and therefore can benefit from the ALSA quirk introduced in kernel 6.12+.
So I’d really find it exciting to read/see a “real” comparison (as I don’t own a Digiface myself).

-----

Regarding the specific points:
1) About Jack:
As far as I know, Jack is a software server/client daemon that runs on top of ALSA. So in theory, it could introduce additional latency. But I am not a Jack expert...

2) About XQuartz:
I noticed the logo https://www.xquartz.org/Xlogo.png in your title bar in the screenshots. That’s why I assumed you were connecting remotely to a Linux system.

3) About “configure ALSA correctly”:
If you check the kernel changelogs – see:
https://git.kernel.org/pub/scm/linux/ke … q=Digiface
you’ll see that this is indeed an ALSA quirk that allows ALSA to communicate directly with the Digiface.
    •    ALSA is the Linux kernel’s interface for direct audio hardware communication.
    •    The Mac equivalent is the RME driver using CoreAudio.
So to truly compare the systems, you’d need to get the RTL Utility to work directly with ALSA.
(But I don’t know your Linux system config – hard to say what the issue might be in your case.)

4) “Linux always uses CC mode – use CC mode on your Mac”:
You’re absolutely right – thanks for pointing that out.
Sorry, I totally forgot that the DF USB doesn’t support CC mode at all. Thus, what I wrote was nonsense in that context.

5) Use same sample buffers on both systems:
As mentioned – to really compare things, your DF would need to run directly via ALSA.
I did measure latency via ALSA on my FF802 under Linux, and afair it was only around 1 to 2ms higher than on my Mac Studio M1.
But that’s not really meaningful because the FF802 has no kernel support under Linux.
So I can only compare CC mode(s) (generic ALSA USB module, modified with some PCM stream adaptions). Far away from direct kernel support...

6) A system with drivers vs. a system without drivers:
You’re absolutely right again – same reason as point 4.
I really should have looked into the DF manual beforehand…

7) “This makes no real sense (in my mind)”:
Yes – maybe I’m not seeing it from a typical end-user perspective.
But I completely understand if someone doesn’t have the time or energy to go deeper.

8) Silicon vs AMD/Intel:
I just wanted to point out that it makes no sense to compare the CPU architecture directly. Silicon chips and macOS are both designed by Apple as a tightly integrated system, whereas AMD/Intel CPUs run on a broad range of hardware and OS combinations with different optimization targets. A direct performance or latency comparison is therefore not necessarily meaningful unless all variables are strictly controlled and similar (what is impossible, afaik).

-----

Perhaps it’s a bit embarrassing to admit. I really have no experience with kernels or drivers. 
But if it turns out that the kernel patch (via ALSA directly) actually achieves similar performance (or could), then it might be worth investing a some time to try to understand the code or what those folks did exactly. Maybe the same approach could be extended to other devices or experimented with further...(?) - just from the perspective of a private Open-Source Fan.

It seems rather unusual to see kernel-level latency over 13ms with at least a 128 sample buffer. So, my impression is, that sth is misconfigured.

Again - Nothing personal to anyone. Peace!

“Do It For Her”
My Gear: Bontempi Magic light Keyboard

20 Reply by maggie33 (edited by maggie33 2025-05-17 05:59:01)

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

What just came in my mind:

Related my post above - point 3):
It seems that the DF could have another pid (0x3fa0) too. I mean, if this matches your DF, it might be necessary to use at least kernel 6.13-rc2 to be properly recognized by alsa…

See:
https://git.kernel.org/pub/scm/linux/ke … e3584bfb50

Edit: Sorry again. Overseen you use
- Liquorix kernel version 6.14
Forget it…

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • nuri
  • ADAT user
  • Offline
  • Registered: 2016-04-20
  • Posts: 23

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

I hope it's okay to leave a few questions unanswered. We could talk endlessly about these topics, which are already discussed at length on many forums.

I just wanted to show that a small Mac Mini M4 performs much better (in terms of latency) than a Linux system with an equivalent CPU (in terms of processing power).
Yes I could spend hours, weeks or even months to tune the Linux system but I cannot afford it anymore (I have a wife, small childrens, house, job, friends... and I want to make music!).

Fact is, pro audio users can not take advantage of the real time capabilities of the Linux kernel.

The rest of the discussion, if any, should take place here:
https://forum.rme-audio.de/viewtopic.php?id=27309

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

I hope it's okay to leave a few questions unanswered.

Sure. No problem.

I just wanted to show that a small Mac Mini M4 performs much better (in terms of latency) than a Linux system with an equivalent CPU (in terms of processing power).

Yeah, I think your personal point of view was already understood by all participants of this thread.
Mini M4 was a good choice...

The rest is clear, too. Thanks.

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • Registered: 2021-09-15
  • Posts: 19

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Luckily in my use case latency is not a problem smile

I am curious how it comes that the DF USB is „suddenly“ supported by Linux. As far as I know DF USB has no CC mode. Did some nice guy wrote some driver code? Would I have to install something? Or is it just plug&play?
Thank you!

24 Reply by kd

  • kd
  • AD/DA expert
  • Offline
  • Registered: 2016-10-07
  • Posts: 52

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

nuri wrote:

I

I just wanted to show that a small Mac Mini M4 performs much better (in terms of latency) than a Linux system with an equivalent CPU (in terms of processing power).
Yes I could spend hours, weeks or even months to tune the Linux system but I cannot afford it anymore (I have a wife, small childrens, house, job, friends... and I want to make music!).

https://forum.rme-audio.de/viewtopic.php?id=27309


Last week, I tested UFX+ under Pipwire.

The latencies look much better now (cc). Something is happening in the Linux world...
And with the help of small tools for Pipwire, there are also a lot of cool configuration options, which were previously unthinkable.
MADI Loop 96 kHz, and so I have extremely fast channel strips at the hardware level, which I will test next week under Linux...
Linux without manufacturer drivers must be at least responsive as a PCI device.
MS OS is Windows 7 (optimized), still the fastest for me under Windows. W11 still doesn't stand a chance there.
MAC is still the most perfect overall package.

  • ramses
  • ramses
  • DAW Mastermind
  • Online
  • From: UTC+1
  • Registered: 2012-10-14
  • Posts: 15,590

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

I got the propaganda now. :-) Can you provide comparable numbers?

BR Ramses - HDSPe MADI FX, M-1620 Pro D, 12Mic, UFX III, ADI-2 Pro FS R BE, Nuendo 15, Win10 IoT Ent

26 Reply by AutoStatic (edited by AutoStatic 2025-09-23 21:41:04)

  • Registered: 2014-04-22
  • Posts: 17

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Recently I bought a Digiface USB and I can run it reliably with a buffer size of 16 on my Debian 12 machine. I've attached a screenshot. Not nearly as good as MacOS but for me this is more than usable. I've also done some measurements with jack_iodelay and those were almost exactly the same.

RTL Utility
https://downloads.autostatic.com/music/rme_digiface_rtl.png

jack_iodelay

   213.608 frames      4.450 ms total roundtrip latency
    extra loopback latency: 165 frames
    use 82 for the backend arguments -I and -O

aplay -l

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: USB23800125 [Digiface USB (23800125)], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

AutoStatic's Website

27 Reply by AutoStatic (edited by AutoStatic 2025-09-23 21:48:15)

  • Registered: 2014-04-22
  • Posts: 17

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

maggie33 wrote:

Again, you are comparing "apples with pears" here.
- jack is always an additional on top SW Layer. This will always add latency.

JACK does not add any latency: https://jackaudio.org/faq/no_extra_latency.html

AutoStatic's Website

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Correct. Learned this already in the meantime...

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • Registered: 2025-10-28
  • Posts: 5

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

I think the culprit for the extra latency is the class compliant ALSA driver of Linux.

I have experimented a lot with a Babyface first generation, I ended up writing my own sort-of-driver (very rough, no total mix or anything like that) to use it in Windows mode rather than CC, and I reduced the latency to levels comparable to ASIO on Windows.

I now use an audio card with Toslink and I2S to communicate with the Babyface, and the latency is exactly AD/DA specs (43 + 28 samples) + whatever buffer I use with ALSA/JACK (plus 17 samples, probably the optical conversion does add an insignificant amount of latency).

All of this to say that if you have the opportunity to use  ADAT / SPDIF, you should smile

30 Reply by ramses (edited by ramses 2025-10-28 10:39:46)

  • ramses
  • ramses
  • DAW Mastermind
  • Online
  • From: UTC+1
  • Registered: 2012-10-14
  • Posts: 15,590

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

I can't support this, but maybe it gives you an idea.

I heard different kernel exist to support audio processing:
1. Normal kernel is only for the usual audio playback and maybe "light" DAW work.
2. Low latency kernel with full preemption takes care that audio related processes like JACK, ALSA, PipeWire are not so frequently blocked by kernel operations.
3. Realtime Kernel for nearly full real-time ability of the kernel, so that all areas of the kernel can be preempted by realtime threads.
4. HiFi or Pro Audio kernel, which is a special customized kernel based on low latency- or RT-kernel. Contains additional scheduler tweaks and predefines the priority of certain audio-processes like jackd, pipewire, pulseaudio.

PipeWire / JACK / ALSA—as far as I could read:
- ALSA works driver-based directly with the kernel; there you get latency by kernel scheduling.
- JACK or JACK2 uses SCHED_FIFO threads, which only work with a low-latency or RT kernel.
- PipeWire supports both and uses real-time threads if the system allows, which means rtkit-daemon is active and "Limits" correctly set.

Maybe it gives you an idea.

Side note: this is one of the major disadvantages, that such technologies are split across different kernel solutions and Linux distributions. It is very intransparent from a user perspective. You need to investigate what's missing for your particular Linux distribution and its kernel release (and what's compiled in or missing). Sure, at the end it's all doable, but tbh, it consumes much time and is a pain to have to tweak it, which might break other things if you are not careful.

BR Ramses - HDSPe MADI FX, M-1620 Pro D, 12Mic, UFX III, ADI-2 Pro FS R BE, Nuendo 15, Win10 IoT Ent
  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

buffing_barbell wrote:

I think the culprit for the extra latency is the class compliant ALSA driver of Linux.

I have experimented a lot with a Babyface first generation, I ended up writing my own sort-of-driver (very rough, no total mix or anything like that) to use it in Windows mode rather than CC, and I reduced the latency to levels comparable to ASIO on Windows.

I now use an audio card with Toslink and I2S to communicate with the Babyface, and the latency is exactly AD/DA specs (43 + 28 samples) + whatever buffer I use with ALSA/JACK (plus 17 samples, probably the optical conversion does add an insignificant amount of latency).

All of this to say that if you have the opportunity to use  ADAT / SPDIF, you should smile

Very Cool! Seems, we had basically the same idea wink

Yes, looking into the current snd-usb-audio module (..sound/usb/mixer_quirks.c) covers the BF Pro in CC Mode only. Which is always a compromise to fulfill the CC specs, regarding safety buffers, descriptors, packet lengths, etc... as you already figured out.
This matches my experience.

But I use my FF802 here (don't own a BF)...
I already had first success with it, too. Started writing a first ALSA module (snd-usb-fireface) for FF802 in USB-Mode (instead of CC-Mode). Quite similar to the existing snd-fireface module (which covers firewire connection only, although FW seems to differ a lot to USB).

With first similar results as you had: Latency is lower, All 30 (plus the 4 FX) channels are presented (in contradiction to 22 in CC Mode)...
I play a little around with the safety buffers atm... What I can say for now: It seems all the features are available/accessible as the Mac/Win drivers do.
Full ALSA (amixer/amidi) support is my personal goal, but needs some more diving in to the ALSA api (I am new to this). With keeping in mind to easy possibility to implement the other Fireface USB based Units, too. Looks as everything is possible, but a lot of work has to be done to make really clean code before publishing sth...

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

ramses wrote:

I can't support this, but maybe it gives you an idea.

I heard different kernel exist to support audio processing:
1. Normal kernel is only for the usual audio playback and maybe "light" DAW work.
2. Low latency kernel with full preemption takes care that audio related processes like JACK, ALSA, PipeWire are not so frequently blocked by kernel operations.
3. Realtime Kernel for nearly full real-time ability of the kernel, so that all areas of the kernel can be preempted by realtime threads.
4. HiFi or Pro Audio kernel, which is a special customized kernel based on low latency- or RT-kernel. Contains additional scheduler tweaks and predefines the priority of certain audio-processes like jackd, pipewire, pulseaudio.

PipeWire / JACK / ALSA—as far as I could read:
- ALSA works driver-based directly with the kernel; there you get latency by kernel scheduling.
- JACK or JACK2 uses SCHED_FIFO threads, which only work with a low-latency or RT kernel.
- PipeWire supports both and uses real-time threads if the system allows, which means rtkit-daemon is active and "Limits" correctly set.

Maybe it gives you an idea.

Side note: this is one of the major disadvantages, that such technologies are split across different kernel solutions and Linux distributions. It is very intransparent from a user perspective. You need to investigate what's missing for your particular Linux distribution and its kernel release (and what's compiled in or missing). Sure, at the end it's all doable, but tbh, it consumes much time and is a pain to have to tweak it, which might break other things if you are not careful.

Hi ramses, your points 1. to 4. are partially right, but I disagree regarding your overall statement.

If you mean in 3. the PREEMPT_RT - it was fully merged and enabled in mainline Linux (since Oct 2024 - kernel v6.12). That means everyone "just" to enable it in the config before building the kernel. And almost all distros (at least debian, ubuntu, etc..) offer the precompiled "rt" version via apt. So, its really easy F.ex in debian: sth like "sudo apt install linux-image-rt-YOURARCH" is all you have to do... all dependencies are automatically installed. And you will get an additional entry in grub, if you use it... Quite easy.

Regarding 4. the "special customized" kernel variants - not official supported by main kernel streamline. So out of scope (at least for me and probably most of others...)

Regarding PipeWire / JACK / ALSA - My personal experience: IMHO, If a unit/card is not recognized by ALSA - all the other (on top layered) "drivers"/modules like Jack, PW, Pulseaudio, etc, will never have any chance to "see" or operate with the unit. 

Anyhow, it would be interesting to read your personal experiences, not the "what I have read/heard" stuff.

Additionally I fully support people trying to make their own solutions if they miss sth.

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • ramses
  • ramses
  • DAW Mastermind
  • Online
  • From: UTC+1
  • Registered: 2012-10-14
  • Posts: 15,590

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

As I stated, I have no personal experience, but I hoped it might help.

BR Ramses - HDSPe MADI FX, M-1620 Pro D, 12Mic, UFX III, ADI-2 Pro FS R BE, Nuendo 15, Win10 IoT Ent
  • Registered: 2025-10-28
  • Posts: 5

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

maggie33 wrote:

Very Cool! Seems, we had basically the same idea wink

Yes, looking into the current snd-usb-audio module (..sound/usb/mixer_quirks.c) covers the BF Pro in CC Mode only. Which is always a compromise to fulfill the CC specs, regarding safety buffers, descriptors, packet lengths, etc... as you already figured out.
This matches my experience.

But I use my FF802 here (don't own a BF)...
I already had first success with it, too. Started writing a first ALSA module (snd-usb-fireface) for FF802 in USB-Mode (instead of CC-Mode). Quite similar to the existing snd-fireface module (which covers firewire connection only, although FW seems to differ a lot to USB).

With first similar results as you had: Latency is lower, All 30 (plus the 4 FX) channels are presented (in contradiction to 22 in CC Mode)...
I play a little around with the safety buffers atm... What I can say for now: It seems all the features are available/accessible as the Mac/Win drivers do.
Full ALSA (amixer/amidi) support is my personal goal, but needs some more diving in to the ALSA api (I am new to this). With keeping in mind to easy possibility to implement the other Fireface USB based Units, too. Looks as everything is possible, but a lot of work has to be done to make really clean code before publishing sth...

So happy to see I am not alone in this sort of obsession big_smile

I was also working towards a fully functional driver, but then I started getting worried of annoying RME or something.

Very curious that you looked directly into snd-usb-audio, I tried to figure out where all this extra latency comes from but failed. One funny thing though, which you surely noticed/know already, CC works with isochronous mode, which according to the spec should fire every 0.125ms (did not measure it myself though), while the windows driver (and my own experiment) work with interrupt transfers (at 1ms intervals). So the poor performance of CC is even more puzzling to me.

Anyways, please let me know (or write here) if you make any progress or have any realizations smile

  • Registered: 2025-10-28
  • Posts: 5

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

ramses wrote:

As I stated, I have no personal experience, but I hoped it might help.

Thanks for your suggestions! I also quote maggie33 that kernel behavior does not seem to be the bottleneck.
Anecdotally, I did try a couple of hard real time kernels as well as compiling my own, without any improvement of this issue.

I think the issue here is really the USB stack (whether the USB driver itself or the ALSA CC implementation I do not know). This is supported by the observation that skipping the USB stack (in my case via TOSLKINK and I2S) makes all the mysterious (i.e. not related to buffer size or AD/DA conversion) latencies completely disappear.

Ideally one should be able to explain latency down to the single sample, as RME is able to do with their Windows driver smile

  • ramses
  • ramses
  • DAW Mastermind
  • Online
  • From: UTC+1
  • Registered: 2012-10-14
  • Posts: 15,590

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

How is it with a pcie card?

BR Ramses - HDSPe MADI FX, M-1620 Pro D, 12Mic, UFX III, ADI-2 Pro FS R BE, Nuendo 15, Win10 IoT Ent
  • Kubrak
  • DAW Mastermind
  • Offline
  • Registered: 2023-08-03
  • Posts: 1,477

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

I am not a Linux fan, but do not mind to help, if I can....

I may borrow PCI-E card (RME AIO) to a Linux fan/developer living in Czech Rep., preferably in Prague. I have this card, but so far no use for it (I got it really very cheap... And could not resist. It may be handy one day.), no problem to borrow it for few months.

FF UCX II, Digiface USB, Babyface Pro FS
  • Registered: 2025-10-28
  • Posts: 5

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

There's a audio interface low latency database on the internet (gearspace forum) that shows measurements for the RME HDSPe AIO Pro card on Windows (at 44.1 kHz and various buffer sizes).

Looking at the number, the delay seems to be exactly the sum of
- 2 x <chosen buffer size>
- AD/DA conversion according to the user manual (5+6 samples)
- 16 sample safety buffer (again, like specified in the manual)
- an additional 18/19 samples, which is probably the PCIe stack at work.

So I would expect one would get very similar performance under Linux, but I have no experience with PCIe devices there (I only know graphics cards tend to work quite well lately smile ).

39 Reply by Kubrak (edited by Kubrak 2025-10-29 17:57:23)

  • Kubrak
  • DAW Mastermind
  • Offline
  • Registered: 2023-08-03
  • Posts: 1,477

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Also, inner DSP computing and conversion from/to ADAT takes several samples. So, PCIe stack is less than 18/19 samples (if 18/19 is the rest...).

If one makes ADAT loopback (I mean real loopback, not TM loopback), one may guess (using osciloscope in DigiCheck), how many samples the delay in HW is.

FF UCX II, Digiface USB, Babyface Pro FS
  • Registered: 2025-10-28
  • Posts: 5

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Kubrak wrote:

Also, inner DSP computing and conversion from/to ADAT takes several samples. So, PCIe stack is less than 18/19 samples (if 18/19 is the rest...).

If one makes ADAT loopback (I mean real loopback, not TM loopback), one may guess (using osciloscope in DigiCheck), how many samples the delay in HW is.

Ah yeah, did not think about that. Incidentally, for some time I've been trying to convince myself that I need a real oscilloscope to do these kind of measurements... So far I have not been persuasive enough smile

  • Kubrak
  • DAW Mastermind
  • Offline
  • Registered: 2023-08-03
  • Posts: 1,477

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

I have measured it for Babyface Pro FS, but forgot exact number. It was few samples. Also, when I asked about HW delay in Digiface USB, MC replied that it is few samples.

You would need kind of osciloscope that measures optical signals, in this case. 8-(((

FF UCX II, Digiface USB, Babyface Pro FS

42 Reply by maggie33 (edited by maggie33 2025-10-30 07:29:20)

  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

If one makes ADAT loopback (I mean real loopback, not TM loopback), one may guess (using osciloscope in DigiCheck), how many samples the delay in HW is.

Yeah. Maybe, before buying expensive oscilloscopes... Hope I understood the key point right here...

Longer time ago, I used the RTL Utility (https://oblique-audio.com/) for this similar case.
I wanted to measure the Latency of the Analog AD/DA Converters of my 802 only, I did the following:
First measurement was via TM Loopback, then a second measurement via a physical Analog cable from In to Out (as kubrak mentioned)...
The resulting time delta, between both measurements shows us the physical time delay. With some basic math skills we can calculate how many samples this are...

PS: RTL Utility seems to be only available for Ubuntu x86_64. As I mainly develop on a debian arm64 VM, I noticed, that the Raspi binary worked for me...

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • Kubrak
  • DAW Mastermind
  • Offline
  • Registered: 2023-08-03
  • Posts: 1,477

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

No, this is not exact. Even TM loopback takes several samples.

No, osciloscope is not needed. I have used Osciloscope feature in DigiCheck NG. Got measures input and loopbacked input and estimated the delay from graph (and recalculated estimated lag to clock).

Anyone who has RME running on Win/Mac may use it. Sure, one cannot use it on Linux, but it is interface HW thing, so it should not be different on Linux.

And, I described ADAT loopback (optical connection), that does not involve A/D and D/A, just internal DSP and possible delay in ADAT signal conversion and creation (I do not know, if there is anything substantial, maybe one could guess it from comparison of TM loopback "RTL" and physical ADAT "RTL". "RTL" means no buffer, USB and computer related stuff counted).

FF UCX II, Digiface USB, Babyface Pro FS
  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

"Even TM loopback takes several samples." Thats right, the signal takes some minimal time trough the board...

Sorry, maybe I wasn't clear enough...
Sure, I noticed already, you were talking about ADAT/Optical conversion in your post above...
My personal scenario (the DA/AD Converters) was meant as an example, which could be adapted to ADAT/Opt, too.
If I understood right, the main thing is to be able to compare Win Drivers vs buffing_barbell's Linux driver. And as there is no Digickeck for linux, RTL Utility might help here, as its available for both OSes. So, we could make TM Loopback measurements on Win, the on Linux - just to verify both versions show same values... Then via direct (optical) cable loopback... Of course, this will not be exact sample accurate in comparison to a real oscilloscope, additionally the signal always goes through the OS/CPU/SW. But this might help to indicate potential issues with a custom written driver...

Regardless of this discussion, my personal experience: 10-20 samples +/- (whatever causes them) - not worth the time atm... Maybe in future for fine tuning...

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • Kubrak
  • DAW Mastermind
  • Offline
  • Registered: 2023-08-03
  • Posts: 1,477

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Sure, my initial note was, that part of the time that "cannot be explained" by buffer size and AD and DA conversion times is accounted to internal DSP & Co. work, that may be measured.

One also should consider those, if using hybrid analog/digital processing. Signals have offsets, and it may create phase problems. Mind that 1 sample lag for signal sampled 44.1k and frequency 20kHz means amost exact flip of phase.... The same for 2 samples and 10 kHz.

FF UCX II, Digiface USB, Babyface Pro FS
  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Aye. Thanks. Got it.

“Do It For Her”
My Gear: Bontempi Magic light Keyboard

47 Reply by ramses (edited by ramses 2025-10-30 12:34:39)

  • ramses
  • ramses
  • DAW Mastermind
  • Online
  • From: UTC+1
  • Registered: 2012-10-14
  • Posts: 15,590

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

I remember MC saying that the processing delay inside of the recording interface is not more than 2-3 samples.
Then add conversion time on top for A/D and D/A if the recording interface has converters.

For MADI devices (preamps and converter) this is documented in the manuals, see below.
3 samples for forwarding MADI frames to the next device at single speed (6 samples at double-, 12 at quad-speed).

See:
- Octamic XTC manual, chapter 10.1, Delay compensation: https://rme-audio.de/downloads/octamicxtc_e.pdf
- Micstasy manual, chapter 11.3, Delay compensation: https://rme-audio.de/downloads/micstasy_e.pdf
- ADI-8 QS manual, chapter 9.8, Delay compensation: https://rme-audio.de/downloads/adi8qs_e.pdf

Also interesting is the comment in this manual in the chapter "How Much Zero Is Zero":
- M32 AD manual, chapter 16.3, "How Much Zero Is Zero?" about forwarding delay: https://rme-audio.de/downloads/m32ad_e.pdf

BR Ramses - HDSPe MADI FX, M-1620 Pro D, 12Mic, UFX III, ADI-2 Pro FS R BE, Nuendo 15, Win10 IoT Ent
  • Kubrak
  • DAW Mastermind
  • Offline
  • Registered: 2023-08-03
  • Posts: 1,477

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

Yes, I remember about the same value (2-3 samples) that MC has said.

And it is (more or less) on par, what I have measured for Babyface Pro fs, using DigiCheck and its osciloscope.

Few samples here and few samples there may cause side effects..... I thought, there is no latency, if using digital signal, at first. But I have heard strange things to happen in my setup. And, that was why I have asked MC, if there is certain latency and how much...

One would thing few samples here, few samples there, it does not matter.... But it may matter and it may be hearable. If one does not care about it and routes digital signals in complex way... It is not like working with analog where latency is much, much smaller.

FF UCX II, Digiface USB, Babyface Pro FS
  • From: Germany, Tuvalu, Poland, Chile
  • Registered: 2021-07-27
  • Posts: 1,107

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

...about forwarding delay: https://rme-audio.de/downloads/m32ad_e.pdf

Although the DA conversion stuff is not new for me, it was long time ago I studied this...
However, a few samples are not the first priority on my current dev stage.
But it lead me to look at the M32 Series manual and I wasn't aware regarding the information in chapter 19, which is very helpful for me atm. Thanks for pushing me to this wink

“Do It For Her”
My Gear: Bontempi Magic light Keyboard
  • From: Germany
  • Registered: 2025-02-06
  • Posts: 34

Re: RME Digiface USB: Linux VS MacOS latency performance. Oooooch.....!

The 4.450 ms as measured by AutoStatic made me wonder if the native USB connection is slower than class compliant USB. I don't own a Digiface USB but I ran a test series with jack_iodelay and UCX II optical looped. To rule out software and configuration I booted a manjaro setup iso and installed only pipewire-jack, jack-example-tools, qjackctl and put the soundcard to Pro Audio.
Out of 8 PCs/Laptops from all days and ages, a Comet Lake Thinkpad T14 and a T570 were notably faster than all the others and even stable with 16 samples @48KHz:

    67.000 frames      1.396 ms total roundtrip latency
    extra loopback latency: 34 frames
    use 17 for the backend arguments -I and -O

Comparing
128 samples @48KHz on the T14:

   277.000 frames      5.771 ms total roundtrip latency
    extra loopback latency: 20 frames
    use 10 for the backend arguments -I and -O

128 samples @48KHz on most other PCs/Laptops:

   362.000 frames      7.542 ms total roundtrip latency
    extra loopback latency: 106 frames
    use 53 for the backend arguments -I and -O

5.77 ms vs 7.54 ms difference.

I tried different USB-Ports, hooked up other usb gear and even USB-Hubs didn't fundamentally change anything. Also, BIOS Settings and LatencyMon on Windows didn't point to a correlation.
That makes me wonder if the crackling problem described in https://forum.rme-audio.de/viewtopic.php?id=40531 could also be due to the PC hardware. Chipset or USB-Controller or something.

So far, 4.45 ms of the Digiface is better than 6-8 ms in cc mode on most hardware, but I'm happy to have found something to undercut that and will go forward with a safe and stable 64/48 (3.0 ms), ditch the Multiface (2.75 ms 64/96 was also very good) and maybe also the Mac Mini M1.

UCX II, BBF Pro FS, Quadmic II, PCIe HDSPe Multiface II, AIO Pro