1 (edited by b4rth 2024-01-23 10:21:39)

Topic: Repeatable and deterministic latency [R&DL]

I've read this at a forum from a colleague so to say - not sure the guy wants me to mention his name but here goes:
Repeatable and deterministic latency is what really matters - any and all interfaces have “direct monitoring” capabilities to allow real time monitoring - but will that latency be the same between re-boots? (not over USB it won’t)

RTL is not that important but R&DL is! Especially for parallel processing with outboard hardware. You don't want to ping your RTL every next boot.

Is this also the case for all USB products? Wondering how and if RME fixed it and if I need to switch back to TB for the UFX+.

Re: Repeatable and deterministic latency [R&DL]

It depends on the specific application whether the RTL is relevant.
The values for RTL are stored in the ASIO driver for all analog interfaces on the recording interface (e.g. in Windows) so that the DAW can perform correct latency compensation. RME is known for entering correct values here.
Specifically: 1. the converter latency depends on the sample rate and is much, much lower than the RTL.
2. the RTL depends to a lesser extent on the sample rate, but above all on the selected ASIO buffersize.

What I don't understand about your and your friend's explanations is what should be variable or change after a reboot. The times are fixed and depend on the sample rate and asio buffersize. There is no variance. Even the differences in RTL between USB, TB and PCI/PCIe based interfaces is very small with RME.

At the moment I have no idea what you are getting at. Never heard of R&DL. But maybe you can be so kind to explain it.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14

Re: Repeatable and deterministic latency [R&DL]

I found some of it here:

https://www.tapatalk.com/groups/proreco … 16127.html
For parallel processing - between audio files and then via external hw it is relevant.

Just asking questions, since you don't want variables in audio latency unless you choose to (changing buffer sizes and stuff). So perhaps someone of RME can chime in on this as well. I think RME doesn't have this problems, but I don't read a lot about this - kind of crucial - thing.

Re: Repeatable and deterministic latency [R&DL]

I haven't tested, but I guess latency might vary if one uses more RME interfaces that use the same driver. Say FF UC and FF UFX III. And once one uses the both, and other time former or latter.

I am just guessing..... Latencies may be different for each interface and if one connects FF UC driver reports its latency, if one connects FF UFX driver reports its latency. And if one connects the both? Probably the value of those two that is bigger....

5 (edited by ramses 2024-01-23 19:48:21)

Re: Repeatable and deterministic latency [R&DL]

b4rth, what means "parallel processing" in this context?
I thought you wanted information about repeatable and deterministic latency.
And if I understand correctly, you (or your friend) claim that only with PCIe (not USB) it is guaranteed to have the same latency after reboot. This claim alone is already strange enough.

Running two different interfaces in parallel is a completely different topic.

I am also asking myself for which use case you ask this and what you are worried about.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14

6 (edited by b4rth 2024-01-23 21:32:10)

Re: Repeatable and deterministic latency [R&DL]

Thank you for your replies ramses and Kubrak

Use case:
For parallel processing (so DAW wave file + 20% mix of heavy hardware distortion for example) this latency should be exactly the same everytime since other wise you have to ping all your FX hardware every time you restart your machine or (perhaps) your DAW/session. MIDI synths is something different btw, since MIDI is sloppy as hell. So we leave that out for now.


I believe this can manifest itself with just one interface already and with hardware FX. So for example Output 3-4 to input 3-4 to add a hardware stereo distortion in parallel. So if you use 2 convertors via ADAT and 1 via MADI - It could be even worse perhaps. But I am not sure. I am also if other RME users have run into these issues or not or if they have best practices to work around this behaviour (if RME has this ofcourse).

So if the claims are true then you need to reping the latency every boot if you are unlucky. Otherwise you end up with phase issues and you need to do a lot of manual editting for example. Anyway I have to test this myself as well and am just curious if this is really the case.

RME would know... If they have solved it with or over USB for OSX and Windows then they should use this in their marketing, as a lot of pros would love this. Perhaps I missed something, but didn't hear a lot about this term and just found out.

So it seems that only PCIe PCI and TB (which is PCIe) are capable of this repeatable and determinstic latency. Again, I am just curious if this is really the case since AVB isn't working like you want to and for Dante you have the same as well etc. Perhaps Ravenna is better - something that is being used by Merging as well and perhaps not without reason. But once again, would love to know more about this.

7 (edited by ramses 2024-01-23 22:14:49)

Re: Repeatable and deterministic latency [R&DL]

I have thoroughly thought through the signal flow and see no real reason why anything should behave differently than usual after a reboot or that PCIe/TB should behave the same and USB differently.
Basically, you should be able to measure the round trip latency yourself with the RTL utility
https://oblique-audio.com/rtl-utility.php

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14

8 (edited by b4rth 2024-01-24 14:20:14)

Re: Repeatable and deterministic latency [R&DL]

I had planned testing this, but so far it is - well - what I expected from RME - solid like a rock! I still wonder how RME has solved this then tbh. Could someone tell some more about it?

Reported RTL    Measured RTL    Measured RTL (ms)    Return Level    Noise Floor    Correlation Factor    Valid        Notes
332        333    6.938    -7.7    -116.4    20.5     True [RME analog o8 to  analog i11 RME]
332        333    6.938    -7.7    -116.5    20.5     True [RME analog o8 to  analog i11 RME] Reboot
332        333    6.938    -7.7    -116.4    20.5     True [RME analog o8 to  analog i11 RME] Reboot
332        333    6.938    -7.7    -116.5    20.5     True [RME analog o8 to  analog i11 RME] On/Off of UFX+
332        355    7.396    0.8    -99.2    54.7     True [RME via ADAT to Alesis AI3 -> o3 to RME i11]
332        355    7.396    0.8    -99.2    54.8     True [RME via ADAT to Alesis AI3 -> o3 to RME i11] Reboot
332        355    7.396    0.8    -99.2    54.7     True [RME via ADAT to Alesis AI3 -> o3 to RME i11] On/Off of UFX+

Some-more-added-details-edit:
Buffer: 128 Samples
Samplerate: 48K

9 (edited by ramses 2024-01-24 11:45:38)

Re: Repeatable and deterministic latency [R&DL]

Many thanks for taking the effort, delivering real data instead of only citing people from other forums where it is still questionable whether their experience, setup, use case matches here. Without such concrete information, it would have lead to unnecessary discussions.

And tbh, I see no reason why this should not be "sample exact" like you found out (always same value).
Really, I thought about the signal flow and how packets are transferred.
OK, I am neither RME not the developer here, but that was my understanding and expectation, that it works this way.

Two additional comments
- technologies like SteadyClock remove any jitter to a minimum if an RME device receives a clock from another unit
- devices like ADI-2 DAC/Pro, ADI-2/4 are designed to use even as clock-slave their own FS clock for DA conversion (and AD conversion, except ADI-2 DAC which has only DA) and you can use the Bittest to validate lossless transport "end to end" from audio player on the computer until shortly before D/A converter.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14

10 (edited by ramses 2024-01-24 12:06:46)

Re: Repeatable and deterministic latency [R&DL]

Now where you delivered data, I also do

Patch cable on UFX III between AN3 IN and OUT, these are three RTL measurements using RTL Utility.
3x, then reboot of Windows 10 PC and again 3x measuring after reboot.

Result: always "static" values of 132 samples RTL and the same RTL of 2,993 which is being reported by my DAW (Cubase) as reported by the RME ASIO driver which contains these correct values so that a proper latency compensation can be performed by the DAW.

https://www.dropbox.com/scl/fi/ow8p5cm4nvbluta7tqtu8/2024-01-24-RTL-Utility-UFX-III-44.1-kHz.-32-samples-ASIO-buffersize.jpg?rlkey=hlesbw5hzzf6ozacfzlfn8vsq&dl=1

BTW this matches with the values from the RME driver which he reports to the DAW, from which I compiled this table below,
see also this blog article which I wrote to that topic:
https://www.tonstudio-forum.de/blog/ent … cts-en-de/


https://www.dropbox.com/scl/fi/uq202kuorag59jbwpx6kf/2024-01-24-RTL-Utility-vs-values-reported-by-the-driver.jpg?rlkey=oi6x4lk91gbjrmyctinosdqvy&dl=1

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14

Re: Repeatable and deterministic latency [R&DL]

I am running a MADI FX in a Sonnet TB chassis to an M3 Max MBP. I get the exact same latency every single time!

12 (edited by b4rth 2024-01-24 14:52:51)

Re: Repeatable and deterministic latency [R&DL]

ramses wrote:

Many thanks for taking the effort, delivering real data instead of only citing people from other forums where it is still questionable whether their experience, setup, use case matches here. Without such concrete information, it would have lead to unnecessary discussions.

And tbh, I see no reason why this should not be "sample exact" like you found out (always same value).
Really, I thought about the signal flow and how packets are transferred.
OK, I am neither RME not the developer here, but that was my understanding and expectation, that it works this way.

Two additional comments
- technologies like SteadyClock remove any jitter to a minimum if an RME device receives a clock from another unit
- devices like ADI-2 DAC/Pro, ADI-2/4 are designed to use even as clock-slave their own FS clock for DA conversion (and AD conversion, except ADI-2 DAC which has only DA) and you can use the Bittest to validate lossless transport "end to end" from audio player on the computer until shortly before D/A converter.

No need to thank me. I regard the guy highly as he has mixed countless hit records and really knows his stuff. But perhaps he never used RME.

edit: I was away for lunch and see that you guys have added important stuff as well. Many thanks ramses and mlprod!

13 (edited by ramses 2024-01-24 14:38:11)

Re: Repeatable and deterministic latency [R&DL]

b4rth wrote:
ramses wrote:

Many thanks for taking the effort, delivering real data instead of only citing people from other forums where it is still questionable whether their experience, setup, use case matches here. Without such concrete information, it would have lead to unnecessary discussions.

And tbh, I see no reason why this should not be "sample exact" like you found out (always same value).
Really, I thought about the signal flow and how packets are transferred.
OK, I am neither RME not the developer here, but that was my understanding and expectation, that it works this way.

Two additional comments
- technologies like SteadyClock remove any jitter to a minimum if an RME device receives a clock from another unit
- devices like ADI-2 DAC/Pro, ADI-2/4 are designed to use even as clock-slave their own FS clock for DA conversion (and AD conversion, except ADI-2 DAC which has only DA) and you can use the Bittest to validate lossless transport "end to end" from audio player on the computer until shortly before D/A converter.

No need to thank me. I regard the guy highly as he has mixed countless hit records and really knows his stuff. But perhaps he never used RME.

You are absolutely right, and I would rather not criticise him too much. Who knows what happened there in the past. But this is not really relevant, relevant is that you and me could validate with different HW, that all is OK and that USB has the same quality as PCIe/TB in that regard.

BR Ramses - UFX III, 12Mic, XTC, ADI-2 Pro FS R BE, RayDAT, X10SRi-F, E5-1680v4, Win10Pro22H2, Cub14

Re: Repeatable and deterministic latency [R&DL]

ramses wrote:
b4rth wrote:
ramses wrote:

Many thanks for taking the effort, delivering real data instead of only citing people from other forums where it is still questionable whether their experience, setup, use case matches here. Without such concrete information, it would have lead to unnecessary discussions.

And tbh, I see no reason why this should not be "sample exact" like you found out (always same value).
Really, I thought about the signal flow and how packets are transferred.
OK, I am neither RME not the developer here, but that was my understanding and expectation, that it works this way.

Two additional comments
- technologies like SteadyClock remove any jitter to a minimum if an RME device receives a clock from another unit
- devices like ADI-2 DAC/Pro, ADI-2/4 are designed to use even as clock-slave their own FS clock for DA conversion (and AD conversion, except ADI-2 DAC which has only DA) and you can use the Bittest to validate lossless transport "end to end" from audio player on the computer until shortly before D/A converter.

No need to thank me. I regard the guy highly as he has mixed countless hit records and really knows his stuff. But perhaps he never used RME.

You are absolutely right, and I would rather not criticise him too much. Who knows what happened there in the past. But this is not really relevant, relevant is that you and me could validate with different HW, that all is OK and that USB has the same quality as PCIe/TB in that regard.

You are right!

I also see btw that once you up the sample rate that as a 'bonus' yet get a much higher noise-floor. Especially with external hw-distortion this could be problematic perhaps? 48kHz seems to be a really good compromise (low noise floor and high speed with RME) :-)

Offtopic: I am now on the lookout for - at some point - replacing both the AI3's for something (hopefully just with TRS) with 16 io. TRS? -> it's just that I don't have to buy other stuff tongue