Carbon Expanded System Converter Latency Not Identical Across Units

[pweinrobe]

Hi Everyone (Especially Avid)

I have a Carbon Expanded system with 1x Carbon acting as Primary and 2x Carbons (running in Pre Mode) acting as units B and C.
They system generally works fine...except:

The units are not time aligned.
Tracks recorded through the primary unit are accurate on the timeline

Tracks recorded through unit B are late on the timeline by 19 samples

Tracks recorded through unit C are late on the timeline by 13 samples

This issue is true with recorded audio tracks as well as committed HW Inserts, on both audio and aux tracks.

It seems that each of these Carbon units likely has a different internal fixed converter latency but that latency is not being correctly reported through the Carbon Expanded communication system, and instead the entire 24 channels are being assumed to follow the converter delays of the Primary unit.

Avid, please help!
Community, can anyone else confirm this result?

Methodology:

For Delay Compensation after Record Pass:
Create a printed click and send to one output on each of the units, returning on an input of each of the units for record. Measure the difference in where the click is printed after the record pass.

For Hardware Inserts:
Create a printed click and duplicate the track 3 times.
Place a HW Insert for Primary on duplicate 1, an HW Insert for Expanded B on duplicate 2, and an HW Insert for Expanded C on duplicate 3.

Commit all the auxes.

The auxes and the recorded tracks present identically, which tells me this issue is all the way back at the hardware level...

Thank you!
Philip

[pweinrobe]

some further tests and results:

Send Click to output of Primary unit
Mult click 3x at patchbay
Return one mult to Primary, one to unit B and one to unit C.

Record click returns

Primary: alignment is perfect
B: 41 samples late
C: 36 samples late

[Darryl Ramm]

Yikes. This is terrible if real. Pro Tools has so many latency related issues I'd not be entirely surprised but I'd have expected others would have noticed this. I don't have any Carbon hardware but I'll make some comments suggestions anyhow...

Originally Posted by pweinrobe

For Hardware Inserts:
Create a printed click and duplicate the track 3 times.
Place a HW Insert for Primary on duplicate 1, an HW Insert for Expanded B on duplicate 2, and an HW Insert for Expanded C on duplicate 3.

Commit all the auxes.

The auxes and the recorded tracks present identically, which tells me this issue is all the way back at the hardware level...

What happens when you do the most simple thing: record the output of the audio click tracks that has the inserts on them to new audio tracks. Does that line up correctly?

Have you trashed prefs and tested starting with a new totally empty session?

What happens if you swap units around, do the different latency errors follow the units or stay with their position in the system?

Are all the units the same 32-bit float variants or are some the 24 bit versions of the Carbon?

Are all the units at the same firmware level?

It should take some difference like that to cause a different actual latency or reporting of a different latency (which the latency correction on inputs or the ADC correction on hardware inserts then would make look like a different latency).

What ADC correction values (at what sample rate) does Pro Tools show for the H/W inserts in these different cases (test that in a new clean small session with no plugins).

I have no idea how or even if the expansion units communicate their latency to the primary unit when combined together. These are not behaving as simple Core Audio interfaces. The latency might well be assumed by the primary unit, more similar to how Digilink hardware works.

What might be interesting it to run all these units as stand alone CoreAudio interfaces and use RTL Utility (https://oblique-audio.com/rtl-utility.php) to both measure the interface Core Audio RTL Log page as well as see what is reported by the driver as latency, go into the log page and CRTL-click on the header and show all the parameters the "OSX Out..." and "OSX In..." this will let you see all the individual latency metrics the CoreAudio driver is reporting. I have no idea if a Carbon can be used as a Carbon Pre and then also behave as a Carbon Pre AVB interface or if you take it out of that and it's a full Carbon unit. If full units then it would be interesting if RTL Utility can measure latency for the Pro Tools AVB device as well and what values you get, but here we have no idea if that means anything useful. Still it would be interesting to see if you see differences between the units.

If nothing else for H/W inserts you should be able to a use the ADC +/- settings to adjust the values on each track with a H/W insert on it, or corrected using the I/O Hardware Insert Delay if the delay time is positive.

[Matt Hepworth]

Are any of your Carbons the 24 bit version? What happens when you mult an EXTERNAL click into each? Do they align?