I/O Ping value changes randomly (Logic, RME, Focusrite)

[stormymondays]

I recently expanded my I/O with a Focusrite Clarett Octopre, which is connected to my RME Fireface 802 via ADAT.

I use a bit of outboard gear, using the I/O plugin in Logic Pro X. When I was using the RME only, the "ping" would always report 0 samples. However, when I send or receive audio through the Focusrite, the "ping" reports a delay that varies from +4 to +32. The problem is that the ping value can change later on the same session!

Is this expected? Do I need to re-ping all I/O plugins before doing the final bounce in order to avoid problems? Any ideas what can be causing the change in values?

I've tried using the RME as master clock, Focusrite as master clock, clocking via BNC cable, none of that makes a difference.

[Hugh Robjohns]

I can understand why you suspect a clocking issue between the two boxes -- I would too.

So, what exactly is the clocking arrangement you've settled on at the moment?

H

[stormymondays]

Thanks for chiming in, Hugh!

When I first noted the issue, I had the RME as master, Focusrite as a slave, using a BNC cable to clock it.

Right now I have the Focusrite as the master, clocking via ADAT. I've tried all possible combinations, and they don't seem to be related to the issue.

It makes sense to me that there's unreported latency with the Focusrite via ADAT, since the RME interface has no way of knowing what the latency of the external box is.

What puzzles me is that I was expecting to always have the same ping values. Having the values drift on the same Logic project is a bit worrying.

Shouldn't a AD or DA conversion always take the same amount of time? Can the temperature of the unit affect the conversion?

[Hugh Robjohns]

You're right, there may well be some additional latency via the ADAT port, but it should be a stable amount. The fact that it's varying suggests to me some dropped samples somewhere, or the ADAT clock phase is varying.

Have you tried making the Focusrite the clock master, but use a word clock from that to slave the RME -- in case the RME is struggling with the embedded ADAT clock?

Also, what happens if you send a high-pitch sine tone around the loop (DAW > RME > FF analogue out/in > FF > RME > DAW). I'd use a tone of 3kHz or higher. Any audible glitches or clicks?

Might be worth dropping RME a line to ask if they've noticed this issue before.

H

[stormymondays]

I have tried all variations, I think. I seem to remember that when the Focusrite was the master, the RME wouldn't accept BNC Wordclock from it, but I just have to retry everything, possibly restarting the units after each change.

I will try the sine tone test, good idea.

I'm in touch with RME and Focusrite support, no luck so far though. RME has also asked to run a digital loop test, which I haven't done yet - I need to crawl through a tight space to unplug and replug!

[James Perrett]

Are the word clock connections properly terminated with 75 ohm resistors? Some gear will handle this automatically while other gear won't.

[Mixedup]

There is a known issue when working with Cubase's ping facility and RME interfaces — my technical knowledge is sketchy here, but to simplify, IIRC, the RME reports a negative latency to the host, as part of a clever way of driving down the interface's real-world latency performance. This, for some reason throws Cubase's ping out of whack, which makes it return a value , usually, of zero (I'd have thought that the ping would just measure the difference between signals and compensate accordingly, but there you go). I've found that the results are a bit hit and miss, and I sometimes get different readings. RME lay the blame at Steinberg's DAW (geddit?), while Steinberg say RME are responsible for declaring the proper latency. But both are aware of the issue. I have no knowledge of how Logic's ping facility works behind the scenes, but I mention the Cubase issue here in case it's a similar situation with Logic.

AD/DA stages for different units can introduce different latency. So there may well be different latency for the onboard RME analogue IO and the Focusrite analogue IO connected via ADAT.

If the units are properly clocked together, whether via ADAT or via Wordclock, then you should be able to set the correct compensation manually: send a transient spike out of the DAW and back in, then zoom in and measure the difference between the two waveforms in samples. Enter that value manually for the delay compensation. (Again, I have no idea whether Logic makes this possible, but some other DAWs certainly do). In fact, this should be a good way to check whether it's actually the clocking or an inconsistency in the ping facility that's causing your problems...

[stormymondays]

Are the word clock connections properly terminated with 75 ohm resistors? Some gear will handle this automatically while other gear won't.

I need to check the manual, I think the RME does. However, clocking via ADAT didn't solve the problem.

the RME reports a negative latency to the host, as part of a clever way of driving down the interface's real-world latency performance. This, for some reason throws Cubase's ping out of whack, which makes it return a value , usually, of zero

From what I understand about Logic and the I/O plugin, what happens is that the RME is correctly reporting latency to Logic, so everything is accounted for behind the scenes. Clicking the ping button results in a 0 samples value, which means there is no unreported latency. That part is working correctly here.

(I'd have thought that the ping would just measure the difference between signals and compensate accordingly, but there you go).

Yes, that's what the Logic I/O plugin does. Sends the ping, measures the difference and compensates the delay.

AD/DA stages for different units can introduce different latency. So there may well be different latency for the onboard RME analogue IO and the Focusrite analogue IO connected via ADAT.

I will do some tests with spikes as well, but the problem for me is not that there is latency via ADAT, which is to be expected, but the fact that the latency changes for no reason

[Mixedup]

Yes, that's what the Logic I/O plugin does. Sends the ping, measures the difference and compensates the delay.

As, ostensibly, does the Cubase one. But it fails with RME and, as far as I can tell, RME alone. Hence the post...

[stormymondays]

Yes, that's what the Logic I/O plugin does. Sends the ping, measures the difference and compensates the delay.

As, ostensibly, does the Cubase one. But it fails with RME and, as far as I can tell, RME alone. Hence the post...

Actually my experience is that it doesn't fail. If I record the external processor, I can null it against the original. In Logic, there really is no unreported latency by RME.

[stormymondays]

Ok I'm going to run a 1 sample impulse through all the I/O, record it back and find out for sure who's lying: Logic, RME, Focusrite, or all of them!

[Mixedup]

The ping problem must be just a Cubase-RME issue then... just figured it was worth ruling that out for Logic.

Will be interested to know what you find out, though.

[stormymondays]

Ok, so I run a whole bunch of tests and I have some good and bad news.

The good:

-Logic's I/O plugin works flawlessly. Whatever the reported delay is when pinging, it is compensated. I've sent an impulse through the I/O, and confirmed it's sample aligned that when recorded back.
-RME's reported delay of zero samples is also correct, as per above.
-The Focusrite AD conversion always takes a delay of 4 samples, no matter how it's clocked.
-The sine test suggested by Hugh worked correctly. No glitches, clicks or any audible problems.

The bad:

-The Focusrite DA "ADAT to line" seems to have a problem, and the ping value drifts randomly. I still need to do a digital ADAT loop to rule out problems in the RME out and/or the cable.

[Hugh Robjohns]

Interesting....

H

[stormymondays]

Ok, so it's not the cable, and the ADAT loopback test was deemed correct by RME (it reported minus 20 samples, in case anyone is curious).

The problem is isolated as follows:

The ping value of the Focusrite DA conversion changes with each restart of the unit. The AD is fine, as stated above. There's a "good" value of 20 samples, which is the most frequent, and it can go higher (or sometimes lower) for no reason. One or two restarts of the unit cures it. Once it's locked, it doesn't change again, or at least today it didn't.

Now, do I have a defective unit? Or is this an engineering problem that will happen with all of them?

[Hugh Robjohns]

Impressive detection work.

I think it's time for a discussion with the clever chaps at Focusrite!

H

[stormymondays]

Impressive detection work.

I think it's time for a discussion with the clever chaps at Focusrite!

H

Sadly, after relaying all the detective work, I'm getting a reply from Focusrite support where they say "providing extended assistance in the realm of testing with 3rd party technologies falls out of the scope of support", even though this unit is designed to extend any third party interface, as stated in their product pages. They also tell me that "The approaches to testing that you are employing are not those we are capable of here", which made me chuckle. Oh, and that they will "forward to the engineering and development departments directly" without any guarantee if I'll even receive a reply.

Lastly, the support email ends with "Vote for Focusrite in the 2018 Sound On Sound Awards" which I thought was priceless

I've tried to send them one final, brief explanation of the problem. I'm also getting in touch with the store to try and get the unit repaired, but I don't have high hopes...

[stormymondays]

Following up on this, I managed to pursue this further with Focusrite support. They have confirmed that the results I'm getting are not a problem of my particular unit, but so far they are not recognizing it as an "issue" or "critical behaviour".

They will still escalate it further, but at this point my options are to "align" the unit everyday when I start up the studio, or sell it.

[Neil - FocusriteNovation]

Good afternoon,

Thanks for bringing this behaviour to our attention.

We have now carried out testing in house and we can confirm that the Clarett OctoPre conversion latency at the digital to Analogue stage can vary up to a maximum of 22 samples (Eg. 0.45ms @ 48 kHz). This affects all channels in the same way and does not vary per channel or during continuous use. Latency variation can happen when the unit is power cycled which could impact some use cases.

We are putting steps in place to address this as quickly as possible and update the firmware for any future production. Due to the fact this unit is not field updatable, we will need to get the unit back from you to be updated. I will have someone arrange this with you in your support case.

If anyone else is experiencing this issue please get in touch with us via the contact form on our website and we will be happy to assist in getting this resolved.

Best regards,

Neil Marron
Global Support Manager

[Hugh Robjohns]

Excellent. Thanks for the update Neil. Glad that obscure gremlin has been tracked down and beaten into submission.

H

[stormymondays]

Thanks Neil and the Focusrite team! I'm in touch so I can get my unit sorted out.

Also, thanks again everyone for helping diagnose and troubleshoot this.

Case solved!

[Martin Walker]

Hi stormymondays!

Excellent news, but so let us know that the problem really is resolved when you get our unit back

Martin

[stormymondays]

Hi stormymondays!

Excellent news, but so let us know that the problem really is resolved when you get our unit back

Martin

As promised, I'm chiming in to confirm that Focusrite did solve the issue and shipped a fixed unit! The UK support/tech team was excellent throughout, and I did get a replacement unit in the meantime. Outstanding.

[Drew Stephenson]

Good stuff. I've always found the folks at focusrite really helpful when I've needed to contact them.

[Martin Walker]

Well done Focusrite!

Martin