Dante

Dante Controller software

The Dante audio network’s signal routing must be done via Dante Controller software on either a Mac or PC. Biamp strongly recommends always using the latest version of Dante Controller software. It can be downloaded from http://www.audinate.com. Further information can be found on the Audinate website under Support > Documentation > User Guides.

In order to connect two Dante devices, the user must specify both endpoints using Dante Controller.

Unlike CobraNet and AVB, Dante provides per-channel routing, so each Dante receiving channel (within an Input block) can conceivably come from a different Dante-enabled device. Thus, a Dante input block can receive more than one network stream.

Dante supports fan out on the network (multicasting) allowing more than one receiving device and channel per transmitting channel. There is not a limit to the number of receiving channels for a multicast stream.

Dante Controller software operates in real time, and reflects the current state of the network to which it is connected. For this reason, audio routes cannot be pre-configured before deploying a Dante network.

You can monitor device status and clock status via Dante Controller.

Once the system has been set up, the Dante Controller software can be shut down or removed. The routing information is stored in the Dante-enabled devices themselves.

Since Dante channel routing is done after the Tesira layout has been compiled it is not possible for the software to predict streams and bandwidth requirements as can be done with AVB.

Some firewall and VPN software packages have been observed to block Dante Controller's ability to discover Dante endpoints, or to block responses to queries of device attributes and routing. Devices may not appear in the Routing tab. Pausing or disabling the firewall or VPN software allows Dante Controller discovery and querying to behave normally. In the firewall settings it may be necessary to allow specific ports including 8751, 8800, 55123, and 65117. See Which network ports does Dante use? for more details. 

Encoding bit-depth

The default bit rate for all Tesira Dante endpoints is 48kHz / 32-bit PCM. Tesira does not offer support for 96kHz sample rate.

The Tesira device's encoding bit-depth can be altered using Dante Controller software. Changes require a device reboot via Tesira software's Device Maintenance "Reboot Device" button or power cycle to take effect. Altering the default encoding bit-depth may be required when sending multicast flows to devices which are limited to lower bit-depths.

Dante automatically converts among PCM word sizes (bit-depth) as necessary when creating unicast flows. Multicast flows are encoded at the current setting of the transmit device and will not connect to devices running at a lower bit-depth. To create multicast flows the transmitter bit depth must be changed to match that of the receivers.

Dante won’t connect incompatible audio devices. If bit rates are not able to be matched the devices are not compatible and a fault will be shown. In practice, if Dante Controller software allows a connection to be made, it should pass audio.

Flows: unicast and multicast

Flows are the transmission packets used by Dante between endpoints.

• Each DAN-1 card can transmit up to 64 channels of audio and receive up to 64 channels of audio (64x64) in up to 32x32 flows.
• Each TesiraFORTÉ DAN can transmit up to 32 channels of audio and receive up to 32 channels of audio (32x32) in up to 32x32 flows.
• Each TesiraCONNECT TC-5D can transmit up to 32 channels of audio and receive up to 32 channels of audio (32x32) in up to 32x32 flows.

A set of channels from a particular device is encapsulated in packets called a flow. A flow is a UDP / IP data packet. Flows contain at least 1 channel and up to 4 channels when routed to 1 device (unicast), or up to 8 channels when routing to multiple devices (multicast). A single packet may contain multiple audio samples for each channel.

• The DAN-1 card can have 32 x 32 simultaneous flows, with a total of 64 x 64 channels.
  • e.g. #1: 32 input channels to one DAN-1 from (32) 1-channel Dante microphones would be automatically encapsulated within (32) unicast flows containing 1 channel each. This would use up all 32 available input flows to the DAN-1, even though the input channel count has not been filled.
  • e.g. #2: 64 input channels to one DAN-1 from (16) 4-channel Dante wall plates would be automatically encapsulated within (16) unicast flows containing 4 channels each. This would use up all 64 available input channels to the DAN-1, even though the input flow count has not been filled.
  • e.g. #3: 64 output channels from one DAN-1 to another 64-channel Brooklyn II Dante device would be automatically encapsulated within (16) unicast flows containing 4 channels each.
  • e.g. #4: 64 output channels from one DAN-1 to (32) 2-channel output wall plates would be automatically encapsulated within (32) unicast flows containing 2 channels each.
  • e.g. #5: 2 output channels (stereo program) from one DAN-1 to (32) 2-channel output devices would be manually assigned to (1) multicast flow containing 2 channels. 31 output flows are still available on the DAN-1 for other applications.
• The TesiraFORTÉ DAN can have 32 x 32 simultaneous flows, with a total of 32 x 32 channels.
  • e.g. #1: 32 input channels to one TesiraFORTÉ DAN from (32) 1-channel Dante microphones would be automatically encapsulated within (32) unicast flows containing 1 channel each.
  • e.g. #2: 32 output channels from one TesiraFORTÉ DAN to (16) 2-channel output wall plates would be automatically encapsulated within (16) unicast flows containing 2 channels each.
  • e.g. #3: 32 output channels from one TesiraFORTÉ DAN to another TesiraFORTÉ DAN would be automatically encapsulated within (8) unicast flows containing 4 channels each.

• The TesiraCONNECT TC-5D can have 32 x 32 simultaneous flows, with a total of 32 x 32 channels.
  • e.g. #1: 32 input channels to one TesiraFORTÉ DAN from (32) 1-channel Dante microphones would be automatically encapsulated within (32) unicast flows containing 1 channel each.
  • e.g. #2: 32 output channels from one TesiraFORTÉ DAN to (16) 2-channel output wall plates would be automatically encapsulated within (16) unicast flows containing 2 channels each.
  • e.g. #3: 32 output channels from one TesiraFORTÉ DAN to another TesiraFORTÉ DAN would be automatically encapsulated within (8) unicast flows containing 4 channels each.

A unicast flow is a standard container for up to 4 channels which is created automatically when you configure Dante routing between 2 devices. In connections made to the same receiver, no new flows will be created until all four channels in the most recently created flow are filled.

Unicast flows will negotiate the correct bit depth when a connection is made (e.g. - between a 32-bit device and a 24-bit device, the unicast flow connection will be negotiated to be 24-bit).

Multicast flows must be manually created in Dante Controller, and channels manually assigned to the flow. A multicast flow is scalable based on the number of channels required, and can contain between 1 and 8 channels.

Multicast flows are created using the bit depth settings of the transmitting Dante device, multicast receivers must be at the same bit depth for multicast flows to be established.

If multicast receivers are fixed 24-bit devices it is necessary for the transmitter to also be set to 24-bit

• E.g. - A multicast flow can not be established between a 32-bit transmitter and multiple 24-bit receivers. Instead, unicast flows will attempt to be negotiated to each of the 24-bit receivers. Additionally, a 32-bit multicast flow will be shown as created and ready in the transmitter device - although it is not connected to any of the 24-bit receivers.

You can check the number of transmitted flows using the Dante Controller software (under Transmit Flows in the Transmit tab of the Device View). A notification will appear if there are not enough available flows for the transmitter.

If a transmitter runs out of the available flows, use of multicast flows may be necessary to reduce the number of transmitted flows.

Also, it’s possible for receivers to not have enough flows in some cases, such as when single channels are received from a large number of devices. In such a case, multicast will not reduce the number of flows, so it’s necessary to reconsider the routing itself. A maximum of 32 Dante input devices (at least 1 flow is used per device) can be connected to DAN-1 or Forte DAN.

• When single channel Dante endpoints are used (e.g. - a Dante microphone using 1 flow containing 1 channel) the number of flows will limit the number of connected devices before the DAN-1's 64 channel maximum is reached. An error "No more RX flows" will be indicated. In these cases another DAN-1 card must be added to accommodate more devices. 

If there are not enough flows available for transmission, use the Dante Controller software to configure multicast, and reconfigure the network so that less flows are used. Be careful to keep the number of multicast flows (channels) to a minimum, because multicast flows increase the load that the network is subjected to.

To help manage the multicast traffic on the network it is recommended to enable IGMP snooping on your switches. Dante devices can issue IGMP join and leave messages. When a switch has IGMP snooping and filtering turned on, it will prevent IP multicast from flooding the network.

If you intend to multicast over multiple switches, you will also need to configure multicast router ports.

AES67

Tesira Dante hardware running firmware version releases 3.9 and later support use of AES67, which is a technical standard for audio over IP and audio over Ethernet interoperability. AES67 is a layer 3 protocol suite designed to allow interoperability between a variety of IP-based audio networking systems. AES67 is supported on Tesira Dante-enabled equipment such as DAN-1, TesiraFORTÉ DAN, TesiraFORTÉ X, and TC-5D. AES67 flows and channels are a subset of the Dante flow and channel counts in devices. Further information regarding device specific channel and flow counts can be found here.

AES67-enabled Dante devices use Dante flows when sharing audio with other AES67-enabled Dante devices. AES67-enabled Dante devices support simultaneous use of Dante and AES67 flows, even within the same Dante input and output blocks.

Further details on implementing AES67 with Tesira can be found in the article Using AES67 in Tesira.

Naming rules for Dante

In Dante, devices and audio channels are identified by names and labels that can be customized by users. Device names must be unique, channel names can be re-used across multiple devices. The combination of Device_Name+Channel_Name must be unique on the network for each Dante channel.

For Tesira Dante hardware, names may be assigned to channels and devices only from Tesira software.

By default, all Tesira channels will be given names in the form:

• IN<block number>_<channel number>, where "block number" is a unique integer associated with the Input block when it is created and "channel number" is the channel within the block, starting with 1.
• OUT<block number>_<channel number>, where "block number" is a unique integer associated with the Output block when it is created and "channel number" is the channel within the block, starting with 1.

All Dante names and labels are up to 30 characters in length. Name and label comparisons are case-insensitive; “Guitar” and “guitar” are treated as the same label. Unicode and non-roman characters are not supported.

Tesira devices have a processor hostname for Tesira software and a Dante hostname for the Audinate Dante interface. Automatically generated Tesira Dante hostnames will be unique per device, following the convention:

• TesiraServerxxxxxxxx-DAN1-yy (where xxxxxxxx = the Tesira Server's serial number, and yy = the chassis card slot in which the DAN-1 card is located on Server-IO)
• TesiraForteDAN-xxxxxxxx (where xxxxxxxx = the Tesira Forte's serial number)

As with channel names, the device names can be changed to better reflect the use case associated with the device. Dante hostnames can be changed under Device Maintenance > Network Settings in the DAN-1 (Slot x) tab.

The Tesira must be in an unconfigured state when renaming the Dante hostname.

Device names should follow Domain Name System (DNS) hostname rules. Legal characters are A-Z, a-z, 0-9, and '-' (dash or hyphen). Device names must begin with A-Z (or a-z).

Channel labels may use any character except '=' (equals), '.' (full stop or period), or '@' (at). Channel labels must be unique on a device.

Channel labels do not need to be unique on the network as they are always qualified by device (channel@device). Tesira channel labeling conventions can be seen on the input and output block pages. Tesira device labels can be modified in Tesira software in the Device Network Settings dialog.

When a Tesira configuration is loaded, names are updated on the Dante card. Names will be requested by Dante Controller software, where users can route signals between devices. In some applications it is possible to rename items in Dante Controller software however it is strongly recommended that naming is done in Tesira software only. When names are applied from Dante Controller software they will not persist through a power cycle, reboot, or configuration update in Tesira as they are not part of the Tesira DSP configuration file.

Device names and channel labels

Dante routing is performed using the device names and channel labels. A receive channel can be subscribed to the name of a transmit channel at a device. Example: “Analog L@my-transmitter” describes a channel labeled “Analog L” on a device named “my-transmitter”. Device names must be unique on a Dante network. Channel labels must be unique on the device.

Tesira software only allows unconfigured Tesira hardware to be renamed. This prevents unintentional changes on a live system. 

If a device or channel is renamed, Dante routing considers it to be a different device or channel. If a new device or channel is then given the old name, Dante routing will route from the new device in place of the previous device. Example: The power supply on “stage-box” fails and “stage-box” needs to be replaced. The old “stage-box” is removed, and a new box is plugged in and named “stage-box.” Dante receivers previously subscribed to the old “stage-box” will now automatically restore their subscriptions to the new “stage-box.”

Device names must be unique on the network. If you attempt to rename a device using Dante Controller to a name that is already in use on the network, Dante Controller will notify you and reject the name change. Example: There is an existing device on the network called “device-slot1”. If user attempts to rename another device to “device-slot1”, Dante Controller will notify the user that the name is already in use. The device will not be renamed.

If a new device is added to the network with a name that already exists, a name conflict is detected, and one of the devices will rename itself by appending (2) to its name. This device will not be able to transmit audio until it is renamed.

Note: A device that has been renamed with (2) appended (e.g. “device-slot1(2)”) will not be able to transmit audio until it is renamed. The parenthesis are illegal characters. The device name must be changed by the user to be a valid non-conflicting name before the device can become fully functional.

Tesira device names will be defined by default as “TesiraServernnnnnnnn-Slotnn” where the string TesiraServer is appended by its serial number and the slot housing the DAN-1 card. As with channel names, the device names can be changed to better reflect the use case associated with the device. Devices can be renamed under Device Maintenance > Network Settings in the DAN-1 (Slot x) tab. The Tesira must be in an unconfigured state when renaming the DAN-1.

In Tesira, inputs and outputs are assigned names in the order that the blocks are created. The names denote which block and channel within the block is associated with a given stream on a given device. The first input block would begin with “IN1_1”, the second input block will begin with “IN2_1”, etc. Output channels will be allocated in the same manner, beginning with “OUT1_1” and so on.

The input and output blocks are a Tesira software convention which are not “seen” by Dante Controller, it only knows that the Tesira DAN-1 is a device that has 64 in and 64 out available.

Channel naming and allocation

Channel naming can be done only in Biamp's Tesira software while offline, using the Dante block Properties sidebar. The information is published to the DAN-1 card on upload, and the DAN-1 card subsequently offers the channel names to the Dante network.

Once online, channel routing between Dante devices must be done using Dante Controller software. Note that the Dante card will always indicate its total number of channels (32 or 64) in Controller. Only channels which have associated I/O blocks in the Tesira DSP will have their channels names populated.

Put all Dante IO blocks in one partition

The best practice is to create a Dante IO partition with all of your Dante IO blocks in it, and use partition connectors to pass the audio from the Dante IO to the individual partitions. This allows Dante IO from a single card to be available in multiple partitions and allows you to individually update the partitions without reconfiguring the Dante card itself.

The Dante card is always updated as a unit, so an update to a subset of its channels requires an update to the entire card. This will stop audio across all Dante channels on that card.

If you have multiple Dante IO blocks in multiple partitions which are compiled to the same DAN-1 card (or FORTÉ DAN) then you must update all of the partitions those IO blocks appear in to avoid stopping Dante audio accidentally in a partition you didn't intend to effect.

Set Dante IO blocks "Fixed in unit" option to True

It is strongly recommended that you set all Dante I/O blocks to Fixed in unit = True in the block Properties sidebar. This will prevent the Tesira compiler from re-arranging the Dante channel order if the file is recompiled.

The Dante card itself is either a 32x32 (FORTÉ DAN) or 64x64 (DAN-1) device. Tesira Dante I/O channel blocks each represent a subset of that total number of channels. If you place (4) 8-channel Dante input blocks in a configuration the Tesira compiler will allocate those blocks to the Dante card in the order it sees as the best solution at that time - a different solution may be found the next time.

Setting the Dante blocks to Fixed in unit = True tells the software explicitly which channels in the Dante card you want each block to be assigned to, and locks them there in future recompilations.

Failure to set all Dante blocks to be Fixed in unit = True may result in subscription errors or corrupt channel routing assignments if Tesira DSP files are updated after routing has been done in Dante Controller.

If channels have shifted then:

• clear all Dante subscriptions in Dante Controller (double-click on each Dante receiver device name, select 'Unsubscribe' on the bottom of the channel list.)
• clear the Tesira configuration file from the Tesira devices (Device Maintenance)
• Set all Dante IO blocks to Fixed in Unit = True in the Tesira configuration file
• reload the Tesira system file
• apply the correct Dante routing in Dante Controller 

Connection status

Dante Controller's Device View can be opened by double clicking on a device name in the routing matrix. Device View indicates all crosspoints in the Receive tab. There is a status column which indicates the health of the subscription. 

Tesira Server-IO and Server DAN-1 cards have primary and secondary ports allowing a redundant Dante network. When only the primary network is in use the connection status will indicate a green check for the primary network and a circle and slash icon indicating the redundant network is not connected. This is normal operation. 

Tesira Forte DAN has only a primary Dante port and so will indicate only the primary network status.

If one or more Tesira Dante channels are disconnected (not routed in Dante Controller) then Tesira software will indicate the system warning "One or more Dante flows inactive." In systems running Tesira firmware 3.15 and higher this message can be disabled to prevent the AIS (Alarm in system) and fault lights indicating an issue when Dante some devices are expected to be disconnected, such as a mixing console or other transitory hardware. This is managed on a per block basis on Dante input and output blocks in Tesira software by checking or unchecking the 'Fault when inactive' option in the block's initialization dialog. 

Cable

Dante devices connect via standard CAT-5e or higher network cabling. In most applications unshielded cable is fine. The maximum cable length is 100 meters.

If hops greater than 100 meters are necessary you can use fiber optic cabling. You will need to use a switch that supports fiber connections to send Dante data over a fiber optic cable.

Network switch requirements

Any switch that supports Diffserv (SCP) QoS with strict priority and four queues, and which has Gigabit ports for inter-switch connections should be appropriate for use with Dante.

QoS is recommended for Gigabit switches on networks that share data with services other than Dante.

Dante supports the use of mixed 100Mbps and Gigabit hardware, audio with mixed sample rates and bit depth, and allows the design of network zones with different latencies. Biamp recommends using Gigabit hardware throughout the network. A Gigabit interface is required for channel counts above 32x32 at 48kHz/24bit.

For low channel count (32 or less) applications, a 100Mbps switch may be used as long as it supports proper DSCP QoS, and QoS is active. The use of 100Mbps switches without QoS is not recommended or supported.

Although power management should be negotiated automatically in switches that support Energy-Efficient Ethernet (EEE), it is a relatively new technology, and some switches do not perform the negotiation properly. This may cause EEE to be enabled in Dante networks when it is not appropriate, resulting in poor synchronization performance and occasional dropouts.

When using managed switches, ensure that they allow EEE to be disabled. Make sure that EEE is disabled on all ports used for real-time Dante traffic. If you use unmanaged switches, do not use Ethernet switches that support the EEE function, because you cannot disable EEE operation in these switches.

IGMP snooping and querier

To help manage the multicast traffic on the network it is often recommended to enable IGMP snooping on your switches. Dante devices can issue IGMP join and leave messages. When a switch has IGMP snooping and filtering turned on, it will prevent IP multicast from flooding the network. An IGMP querier IP address must be defined on at least one switch in the Dante network or VLAN. (On Cisco Nexus switch networks this may include enabling PIM sparse, thereby enabling an IGMP querier.) 

If no querier is present then IGMP snooping will cause Dante clock discovery to fail. You will see multiple Leader Clock devices shown in Dante Controller, the Dante devices will lose clock sync and latency will increase until audio stops.

If you intend to multicast Dante over multiple switches, you will also need to configure multicast router ports.

Due to differences in how switch manufacturers implement IGMP snooping, this feature may cause Dante devices to lose the ability to sync their clocks. IGMP snooping may even be implemented differently in different switch families from the same manufacturer. Be sure to read all of the IGMP configuration literature for each switch model in the network to ensure the attributes are properly configured.

A telltale symptom of IGMP snooping configuration issues is when multiple devices are shown as Leader Clock devices in Dante Controller. The presence of multiple Leader Clock devices is a red flag issue which must be resolved before moving forward. In troubleshooting this issue, first confirm a querier is specified on at least one switch in the Dante network or VLAN. If it is still not working properly, disable IGMP snooping on all switches in the Dante network or VLAN to see if it resolves the problem. Re-apply IGMP snooping only if it is determined to be required - it may not be needed.

Spanning tree may interfere destructively with IGMP, if both are desired this should be discussed and tested in conjunction with the switch manufacturer. 

Bandwidth

Dante single-link network limitations are determined by the bandwidth of the endpoints.

The number of channels that can traverse one link in a network is proportional to the link speed.

A link will always slow down to the lowest speed connector on that link; eg. if a Gigabit port on switch A is connected to a 100Mbps Fast Ethernet port on switch B, the link speed will be 100Mbps Fast Ethernet. This is good, because it allows you to mix link speeds in a network without having to do anything complicated.

Audio is transmitted over the network in UDP/IP Packets. A single IP packet may contain audio samples from several audio channels, and may contain multiple audio samples for each channel.

Audio packets can be transmitted using either unicast or multicast addressing. By default they are sent using unicast, but the user can change this to multicast using the Dante Controller. Multicast and unicast can be sent and / or received at the same time on a Dante device. Channels are individually selectable for multicast transmission.

Device discovery: IP addresses

When connected to an IP/Ethernet network, a Dante-enabled device will automatically configure its own IP address and advertise itself to other devices on the network. Dante-enabled devices will automatically discover one another over the network and learn each other’s capabilities (number of input and output channels, sample rates and bit depths supported, etc.).

Dante Primary and Secondary ports must be on their own unique networks. This can be achieved either through the use of redundant switches (preferred) or VLANs on a shared switch. The Dante Primary and Secondary ports should never be connected to a common network.

Networked Dante devices and channels can be labeled with “friendly” names that make sense to the end user.

Dante devices obtain IP addresses automatically by default - so there should be no need to specify static IP addresses unless it is a specific requirement for your network.

• You can configure static IP addresses and host names for one or both of the DAN-1 Ethernet ports using Tesira software. Note that these edits must be done with the Tesira in an unconfigured state (no system file loaded; Device ID = 0). In Device Maintenance > Network Settings choose the DAN-1 (Slot x) tab.
• If your network has a DHCP server, Dante devices will receive their IP configuration using the standard DHCP protocol.
• On a network without DHCP, a Dante-enabled device will automatically assign itself an address using ‘Bonjour’ Zero Config auto addressing protocol by Apple. Devices will automatically assign themselves an address in the range 169.254.*.* (172.31.*.* for the secondary / redundant network, if present).

DAN-1 MAC addresses are visible within Device Maintenance > Network Settings under the DAN-1 (Slot x) tab, choose the Interface Status... button. There are two (2) MAC addresses for each DAN-1 card, use Interface ID: to select between the Primary and Secondary NICs.

Redundancy

Dante offers a full-time redundancy option with permanent primary and secondary audio transmission. Redundancy requires a second distinct broadcast network, either using a second physical switch network (recommended) or via a VLAN isolating the network traffic.

Dante redundancy requires that both the primary and secondary interfaces on any redundant device are connected using the same link speed.

If the secondary network is connected to a device that supports redundancy, it is enabled automatically. Audio data is transmitted on both the primary and secondary networks simultaneously. In the event of a failure on one network, audio will still continue to be received via the other network.

Dante devices that do not support redundancy must be connected to the primary network only.

Dante Controller must be connected to the primary network.

The Secondary Port found on the DAN-1 card is for Dante redundancy only. It does not support the typical default Daisy Chain mode ("Switched" mode).

Cross-connecting the primary and secondary networks will cause errors seen by Tesira as run time faults. Dante Controller must be used to identify issues in Dante streams.

Dante QoS values

Some switches require special configuration to recognize and prioritize specific DSCP values. The table below shows how Dante uses various Diffserv Code Points (DSCP) packet priority values.

Wi-Fi

Wireless LAN (Wi-Fi) is not supported for Dante audio. While possible in principle, the practical limitations of current wireless technology (802.11a/b/g/n) render reliable performance unachievable.

If it is nesessary to add a Wi-Fi access point to the Dante network it should be isolated from Dante traffic using multicast filtering for unregistered multicast. Dante multicast traffic can overwhelm a Wi-Fi device.

Dante Controller software will not function over Wi-Fi. 

Network Ports

• Audinate Dante port requirements can be found here https://www.audinate.com/faq/which-network-ports-does-dante-use
• Additional Audinate Dante network requirements can be found at https://www.audinate.com/sites/default/files/PDF/adding-dante-to-your-network-audinate.pdf
• Audinate Dante Domain Manager has additional network requirements which can be reviewed here https://dev.audinate.com/GA/ddm/technical-notes/network-admin/pdf/latest/DDM%20-%20Info%20for%20Network%20Administrators%20v1.9.pdf

Clocks

An extremely high-quality clock is provided by the Tesira backplane, the card bus references that clock for Master Clock duties within the network unless a higher priority clock is available, such as AVB (when present) or Dante. If these higher priority clock sources are present then Tesira's clock will sync to their clocks.

Dante clocking guarantees that all devices are synchronized to within 1 microsecond or less, and that all devices can play out audio at the level of sample accuracy.

As with AVB, Dante uses a distributed Leader Clock election protocol that automatically selects the best clock for the network, based upon information advertised by each Dante device. This information includes the quality of its clock, clock source, link speed and other parameters, and results in the best clock being elected as the Leader Clock. One device is elected as the Leader Clock to which other devices are synchronized. By default this selection takes place automatically, with no need to manually assign a Leader Clock.

In the event the Leader Clock drops offline audio will continue to flow and a backup Leader Clock will take over. If the Leader Clock fails for any reason, a new Leader Clock will be chosen from the existing Followers within a few seconds. The transition from one clock Leader to the other does not result in any loss of audio. Follower devices “free run” during the period of Leader clock transition.

Most of the time, you do not need to be involved in the Leader Clock selection process. Dante guarantees that the Leader Clock device will be by default the strongest candidate.

To force a specific device to become the Leader Clock you would normally use the Dante Controller to set a Dante device to be "Preferred Leader". If more than one device is selected as the "Preferred Leader", the device with the lowest MAC address will be chosen during a clock election.

Because Tesira is capable of combining and synchronizing multiple network audio protocols, the Preferred Leader flag of a Tesira device's Dante interface cannot be set using Dante Controller. A Tesira device will set its Preferred Leader flag automatically to match the clock propagation specified in the configuration.

Clocks in multi-protocol systems

In a system using AVB and Dante, the protocol providing the master clock will depend on the Tesira configuration file's Media Networks Setup dialog. 

More information about working with multiple protocols in Tesira can be found here: Using multiple networked audio protocols.

Clock heirarchy and propagation in a multi-protocol system must be considered during the design phase.

• If the AVB network has been specified as the Clock Master network, then the Tesira system will try to impose its clock on Dante network:
  • In Dante Controller, the DAN-1 in the chassis with both AVB and Dante card will show “Preferred Leader” and “Enable sync to external" word clock flags set. The AVB card in that chassis is providing the 'external' word clock source. Other Dante devices must Follow that “Preferred Leader”.  
• If the Dante network has been specified as the Clock Leader network, then the Tesira system will impose the Dante clock on its AVB network: 
  • The DAN-1 in the chassis with both AVB and Dante card will not show “Preferred Leader” or “Enable sync to external", and the Tesira device will synchronize its AVB-1 card to the DAN-1 card. 
• It is possible to manually set multiple devices to the "Preferred Leader" state. In the event a Dante network has multiple "Preferred Leader" devices, the Dante devices will negotiate between themselves to determine the correct "Preferred Leader" device. The Dante device with the highest quality Dante chipset and lowest MAC address will become the "Preferred Leader". This will cause a conflict if the Tesira AVB network has been configured to be the Media Master network and the device elected as Dante clock Leader is not the Tesira. The Tesira system will not be able to impose its clock onto the Dante network, and so the AVB and Dante networks will be unsynchronized. In short, if a Tesira DAN-1 displays the "Preferred Leader" flag then no other devices on the network should be set to "Preferred Leader".
• If the Tesira Server / Server-IO has (2) DAN-1 cards installed then one of the 2 cards will show the "Enable sync to external" flag set. This indicates it is aware of another Dante card in the same chassis. If no other Dante device is defined as Preferred Leader then the synced DAN-1 will be elected clock Leader. In this configuration a 3rd party Dante device on the network should be defined as "Preferred Leader". This will allow both of the DAN-1 cards in the shared Tesira chassis to sync to a common external clock and preclude the possibility of a clock loop.
• The Tesira system will impose its own values on the “Preferred Leader” and “Enable sync to external" check boxes to align with the Media Network configuration defined in the Tesira. These will override attempts to edit them in Dante Controller. This is expected behavior.
• Only one device per Dante network may be defined as both “Preferred Leader” and “Enable sync to external" in order to avoid conflicting clocks. This device is automatically made the Leader clock, so all others will sync to this device. "Enable sync to external" indicates that the device is connected to multiple clock sources and prefers to be synced to another clock domain, it is then imposing this clock on the Dante network. 

Dante devices each contain a very high quality VCXO clock, and are synchronized with one another over the network using the IEEE 1588 Precision Time Protocol (PTP). This synchronization requires the use of Diffserv (DSCP) QoS with strict priority and 4 queues in the Dante network's switches.

The source of the Leader Clock can be:

• The internal VCXO clock generated within a piece of Dante enabled equipment, or
• An external clock source which is internally connected to the Dante device (e.g. AVB in a Tesira Server).

There are certain circumstances in which the automatic Leader Clock selection may be inappropriate. For example, a system may have a device that is periodically connected and disconnected, e.g., an input to the network from a stage box or mixing console. This device may not be always present and thus would be a poor choice for a Leader Clock. Using the Preferred Leader setting in Dante Controller, you may designate as a Leader Clock a device (or devices) that is always present for the entire time that the network is required to function.

Latency

In Dante, variation in latency in the network is compensated for at the receiver. Each receiver has an Rx latency setting. This setting defines the latency between the timestamps on the incoming audio samples and when those samples are played out. The typical default latency for a Dante device is 1 ms. This is sufficient for a very large network, consisting of a Gigabit network core (with up to 10 hops between edge switches) and 100 megabit links to Dante devices. Smaller, Gigabit-only networks can use lower values of latency (down to below 200µs). Recommended latency settings are displayed in Dante Controller.

Dante uses a network-centric approach to synchronization using standard VoIP QoS to prioritize clock sync and audio traffic over other network traffic allowing synchronized playout over different audio channels, devices, and networks over multiple switch hops. 

In order to bring latency down to the lowest possible values, a gigabit network should be used. This allows greater freedom to build a high performance, flexible network that maintains fantastic latency performance. Dante offers sub-millisecond latency for all products. (In principle the lowest latency between two nodes connected directly using Gigabit Ethernet is achieved if a single audio sample is collected and then transmitted in its own IP packet. Dante latency has been measured as low as 83.3µs for a gigabit implementation.)

Receivers that are listening to the same audio transmitter using the same latency value are guaranteed to be sample aligned.

Latency in a Dante system is deterministic and guaranteed. A Dante receiver introduces an additional latency before playing out audio to account for delay variation in the network or end device. The user sets this latency with Dante Controller and the value selected should be based upon the size of the network.

Latency can be configured to be different between different devices in the same network, and does not have to be the same for all connections on the network.

Dante allows you to configure low latency connections for critical audio paths, while at the same time running higher latency connections for a broadcast or recording feed where latency is less critical. When 2 connected devices use different latency settings, the higher of the 2 latency values will be used for transmit and receive between the devices.

The minimum latency available for a device connected to a 100 Mbps network port is 1 ms. The Biamp DAN-1 card supports 1 ms and 2 ms latency.

Adding new devices to a network does not affect the latency of devices already in the network. The latency of hardware devices does not depend on the number of audio channels routed, however some devices (e.g. the Dante Virtual Soundcard) may need to use higher latency to reliably process high channel counts. Routing additional audio channels does not change the latency of audio already passing through the network.

Unicast Delay Requests

In some applications it may be necessary to enable Unicast Delay Requests on Dante endpoints to allow devices to sync their clocks with the leader. In systems with TC-5, TC-5D, or TesiraFORTÉ X certain network topologies may be put in place which block needed multicast messages from getting through to Dante endpoints. Enabling Unicast Delay Requests for these devices is recommended.  

Delay requests are messages sent by clock followers to the clock leader to establish the time it takes for data to traverse the network between the devices. By default, delay requests are multicast messages, and in networks with lots of devices, they can add up. Enabling 'Unicast Delay Requests' forces clock follower devices to send delay requests to the clock leader using unicast instead, which reduces multicast traffic.

Note:  Unicast Delay Requests does not have to be enabled on the clock leader, only on the clock followers.

Some older Dante devices do not support Unicast Delay Requests. Before enabling the feature for your clock followers, check that your current clock leader supports the feature, by attempting to enable it for the device. If the clock leader device does not support unicast delay requests, do not enable it on your clock followers (it may prevent your devices from synchronizing). You can however choose an alternative clock leader that does support it, and then enable it for the clock followers that also support it.

Legacy devices

Audinate refers to any hardware running on pre-4.0 Dante FW as a legacy device.

Audinate maintains a firmware library for Dante endpoint hardware. Biamp maintains a firmware library for Tesira products. The numbering of the 2 libraries is unique from one another and uncorrelated. The Dante endpoint is a hardware component of the Tesira device, and inherits its firmware from the Tesira host. Updating firmware on a Biamp Tesira Dante endpoint is done by updating the Tesira device's firmware. Attempting to directly load Audinate firmware to a DAN-1 or FORTÉ DAN Dante endpoint using Dante Controller or other means may corrupt the endpoint and render it inoperable. Always update firmware using Biamp Tesira's software interface or SageVue.

Dante interfaces on Tesira devices running Tesira 3.7.1.5 firmware (FW) or earlier use pre-4.0 Dante FW and should be treated as Dante "legacy devices". 

Tesira 3.8 through 3.10 FW releases updated the Dante cards to the 4.0 Dante FW but Tesira infrastructure does not yet support Dante Domain Manager (DDM). Biamp Dante endpoints running those Biamp FW versions should be treated as legacy Dante devices in DDM.

• DAN-1 and TesiraFORTÉ DAN devices running Biamp FW versions 3.8, 3.9, or 3.10 will advertise themselves within Dante Domain Manager even though it is not supported in those versions. Assigning these devices to the Dante Domain will result in audio not flowing. Devices should be updated to Biamp FW 3.11 or later.

Audio can be routed between subnets by Dante hardware running FW 4.0 and higher. Legacy Dante devices (running pre-4.0 Dante FW) in one subnet cannot act as a boundary device to talk or listen directly to a Dante device in another subnet. Tesira Dante devices can participate within a Dante domain spanning subnets alongside other devices running FW 4.0 or higher, can route audio to and from those devices, and those devices can act as the subnet boundary transmitters and receivers.

Firmware Update Manager

The Tesira's DAN-1 cards, TesiraFORTÉ DAN, TesiraFORTÉ X, and TesiraCONNECT TC-5D only run Dante firmware provided by Biamp via Tesira firmware updates.

Biamp Dante firmware updates are embedded in the Biamp Tesira firmware package and can only be applied using Biamp Tesira software's Device Maintenance > Update Firmware tool. There is no supported method for updating the Dante firmware independent of the Tesira firmware update.

Attempting to load Dante firmware directly to the Dante cards via Dante Controller or Audinate's Firmware Update Manager may result in an unrecoverable device. 

If your system is up to date with the latest Tesira firmware, then your DAN-1 card / TesiraFORTÉ DAN / TesiraFORTÉ X / TC-5D is up to date with the latest Biamp-supported Dante firmware.