CM-1 and XDAB clock interactions

Here are some additional details.

The tightest and most critical clock in the system remains the CobraNet Conductor.  So if there is CobraNet coming into any NioNode of a Project, the Project and the XDAB will lock to the CobraNet Conductor.  If there is no CobraNet being processed, then the internal clock of one of the NioNodes will become the master for project.

So if the CN Conductor is the master clock, and the XDAB has locked to this master, then it would make sense that if the CobraNet is disconnected, the system would fault as the internal clock become the master clock.  And would fault again, as the Nions re-sync their clocks to the CobraNet Conductor when it comes back on line.

A short post on the Blog by Michel, called "XDAB Leader", is helpful to understanding this topic.  Perhaps Michel has some additional insight to add (and perhaps the original should be moved to this site).

Phil, I've run into this in the past. If the Nions are using CobraNet, then the XDAB clock is basically dependent on the conductor. We tried many things but found that the only complete way to make sure you don't have XDAB renegotiate upon conductor changes, is to use a conductor external to the Nions. Since the Nions default to high conductor priority, this has to be manually set using some kind of SNMP manager. Keep in mind that conductor capabilities depend on the CobraNet interface so not any CobraNet device can become a reliable conductor for a Nion system, specially for a large system.

Some clarification:

When a set of NIONs are connected by XDAB, they all share a common clock.  One of the NIONs is the clock master for the rest.  You can force a particular unit to be the XDAB clock master by editing the NioNode device properties and increasing its XDAB Clock Master priority.  This is, in fact, recommended.

If one of the NIONs is connected to CobraNet, its Clock Master Priority is increased automatically.  It then receives its clock from the CobraNet interface, and drives the clock over XDAB to all the other units.  If the CobraNet interface in the NION is not the CobraNet conductor, it is receiving its clock from some other CobraNet device on the network (the conductor).  If the CobraNet conductor changes, there is a momentary disruption of the clock data going to the NION.  This disruption is passed to the XDAB and can result in  an XDAB clock reconfiguration, causing all audio to drop out momentarily on all NIONs in the cluster.  If you see  "xdab reconfiguration" in your log file, this is probably due to a conductor change.

Because of this, I recommend that you increase the CobraNet conductor priority for the NION CobraNet interface.  You can do this from the NioNode device properties.  This way, a conductor change will only occur if the NION itself is disconnected from the network or is shut down.

If you have multiple NIONs in an XDAB cluster with CobraNet in use, or if multiple clusters are connected by CobraNet, life gets a little more complicated.  I'll address this in a later post...

Running standalone the,  CobraNet card (CM-1) supplies the master audio clock to the NION, which in turn feeds it back to the CM-1.
In an XDAB cluster the rules change a little. The same rule applies if the device is the XDAB master. But if the NION is an XDAB slave, then the NION will get its master clock from the XDAB and then feed that to the CM-1. So the CM-1 master clock is coming from XDAB in a NION that is not the XDAB master.

SO.. IF you have an XDAB cluster
THEN .. all of the CM-1s in the cluster can be performers, i.e. they can all get their audio clock from the same CobraNet device outside the cluster and it doesn't matter which NION in the cluster is the XDAB clock master.

BUT... (( AND THIS IS IMPORTANT))   if one of the devices in the XDAB cluster is a conductor, THEN it MUST also be the XDAB clock master. If you allow a range for priorities and let the NIONS automatically negotiate this, then the cluster should wind up with the XDAB master as the conductor node automatically.  But if you explicitly set priorites to override this and make the wrong choice, you could end up with the wrong relationship between XDAB master and CobraNet Conductor within the cluster.

If the XDAB master is also a CobraNet  performer and  one of the XDAB slaves is the  CobraNet conductor, then the XDAB master is trying to generate its master clock from the CM-1 conductor. But the Conductor is an XDAB slave and so is getting its master clock from XDAB.  So you wind up with an open loop as far as clock sync closure goes.

When this happens you can get a VERY long settle time on the clock sync between devices in the cluster with multiple resets and XDAB resyncs.  Getting everything back in sync becomes just a random timing  affair of what resets  when and allows the clocks to sync up. Eventually it can recover but only by chance. Theoretically it should never recover if all the devices are running and are out of reset when in this configuration.

I'll try to write up something more complete and definitive on this but if you just remember this then you will be OK:

If one of the NIONS in an XDAB cluster is the CobraNet conductor, then that NION must also be the XDAB master.

The project that initiated this post is still haunting us!
The added complications are:
Optocore system running at 96kHz, feeding AES (124ch) to multiple Nio-AES cards in XDAB cluster of 12x n6 (also 96kHz).
CobraNet running at 48kHz connect NIONs to another system (Audia), using down-sampling in NION.

Before going into all the permutations that have been tried, has anyone done battle in this area?