Shame…

Digiface with Reaper on Linux would be a killer setup.

    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.

...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

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.

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

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.

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...

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).

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...

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

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

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.

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 ).

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.