1 (edited by etluxperpetuam 2013-03-20 08:29:31)

Topic: UFX: Different Driver Latency Offset Results: FW v. USB

I've been trying to get a grip on round trip latency (RTL) for a while now testing various DAWs with different interfaces.

I've done loopback tests with a 1 sample long audio click to be able to get sample accurate measurements. I've done the tests with a balanced patch cable on the analog end and a Monster optical cable for ADAT.

When I was doing my initial batch of tests in Spring'12, the UFX USB driver was delivering perfect offset corrections. Exactly 0 samples difference between source and destination. I don't exactly remember the driver version but I think I was on 1.66 at the time. Only with Pro Tools I was reading a 1 sample difference between source and destination.

Now I am on USB driver 1.78. It seems that offset perfection has gone off a bit. In Logic and Cubase I'm reading +3 samples RTL offset difference. With Pro Tools I was initially reading 4 samples. After some experimentation I've come to realize that having Delay Compensation on takes that values down to 3 as well. I guess this was also the reason for the 1 sample offset difference I was reading in Spring'12.

I haven't yet tried downgrading the driver thinking that I wouldn't want to use an outdated driver. I could try though.

Anyhow, as I indicate on the subject line, the FW driver is behaving differently; it's still working perfectly in terms of RTL offset correction.

Finally, with my recently purchased Babyface I'm getting varying readings.

With Logic, both manual measurement and I/O Plugin measurements read 0 samples difference b/w source and dest.

With Cubase I'm reading 1 samples difference.

With PT I'm reading 1 samples with Delay Compensation, and 2 samples with DC off.

Here are some setup details:

Regular MBP Mid 2012 / Ivy 2.3 / 16GB RAM / 10.7.5 up to date 64 bits Kernel
Cubase 7.0.2 / PTHD 10.3.3 / Logic 9.1.8 (all running 32 bits mode)
UFX/Babyface USB Driver 1.78 / UFX Firmware 352-151-341 / Babyface Firmware 203
Test SR: 96KHz w/ 24 bits.

I know these values are negligible. Nevertheless, when I was doing my shopping shootout b/w a UA Apollo and the UFX, the UFX was performing perfectly in this regard as opposed to the Apollo's appalling / very disappointing / huge offset correction error. I'm not even going to talk about the performances of my old stock of M-Audio interfaces. In any case, this reliability and perfection was one of the important reasons for my choosing the UFX. Why not have it go back to it's original glory with a perfect score on both drivers?

So the question: any ideas why I'm experiencing this difference between the drivers?

Thanks!
Derin.

p.s. If you think there might be something wrong with setup and testing methodology, please ask away. However, I honestly doubt this to be the case. And I'm still getting perfect readings on the FW side.
- I've tried a direct USB connection as opposed to my regular connection over a very good quality hub (Digi Hubport 7/c) and that didn't seem to make a difference
- Spring'12 tests were conducted on a Late 2012 MBP / Sandy 2.5 / 16GB / 10.7.3. One obvious difference is USB3 presence on my current MBP.

2

Re: UFX: Different Driver Latency Offset Results: FW v. USB

The roundtrip offset changes by about 3 samples when you activate the option 'DSP for Record' in the Settings dialog. I expect that you have  changed that setting in the USB driver so now see the small offset. Please check.

Additionally it is nearly impossible to get exact 0 samples offset in single speed (up to 48 kHz). The dealy is not exact a sample, but smaller. That's why only at higher sample rates the compensation can give reliable 0 samples values.

Regards
Matthias Carstens
RME

Re: UFX: Different Driver Latency Offset Results: FW v. USB

Wow, that was quite simple then, wasn't it! :-)

Thanks Matthias, that was the issue indeed - I shouldn't have missed trying that one to begin with! hmm

Now, as I said, I did conduct the tests at double speed with both UFX and Babyface.

So what do you think might be the reason for the differences I'm reading with the Babyface;

Logic -> 0 samples
Cubase -> 1 samples
PTHD ADC on -> 1 samples (ADC off ->2)

I understand this isn't something to fret really. But I'd still like to understand why this might be - even at double speed; why the difference b/w DAWs and why with the Babyface and not the UFX?

Thank you!

Re: UFX: Different Driver Latency Offset Results: FW v. USB

My guess would be: Rounding differences in different applications?!

Re: UFX: Different Driver Latency Offset Results: FW v. USB

Hi Timur - and thanks for your input!

Yeah that crossed my mind too. But why would you think this would seem to affect the Babyface and not the UFX?

Re: UFX: Different Driver Latency Offset Results: FW v. USB

Different converters with different inherent latency leading to different "calculated" results?!

Re: UFX: Different Driver Latency Offset Results: FW v. USB

As in, the Babyface converter hits some "middle spot" which Logic interprets as 0, but PT and Cubase as 1?

Possibly...

8 (edited by Timur Born 2013-03-20 12:44:21)

Re: UFX: Different Driver Latency Offset Results: FW v. USB

That would be my guess, but others likely know better. HeadScratch

Up to now I always thought these calculations to be sample based, though.

Re: UFX: Different Driver Latency Offset Results: FW v. USB

You know actually the waveform itself might be supporting this option.

I had noticed that with the UFX the recorded 1 sample long audio click was almost identical to the source audio click: a 1 sample wide tall box around -3 dB followed by a sample long box very close to the 0 crossing line. With the Babyface, however, the recorded audio click looked much different from the source. First a 1 sample wide box at say -6 dB followed by a taller 1 sample wide box at say -4 dB. So instead of only one tall sample, I got two conjoining tall samples… This was much easier to spot with Cubase because of the way it represents the waveform at the sample level - one rectangular step per sample…

Yeah, you're right; this is probably "others likely know better" über-geek territory :-)