Dante Network Considerations
Click here to see this page in full context

 

Dante Network Considerations

SERVER and SERVER IO DAN-1 Card

The Dante DAN-1 card, based on Audinate's Brooklyn II Module, allows Tesira SERVER or SERVER IO devices to share digital audio with other Dante-enabled devices, both from Biamp and other manufacturers. Each DAN-1 card can transmit up to 64 channels of audio and receive up to 64 channels of audio using up to 32 flows in each direction.

Each input and output block of channels can be defined with between 1 and 64 channels of audio (for a total of 64 inputs x 64 outputs allocated to all blocks per DAN-1 card ). Each Dante channel will have an explicit name. Dante DAN-1 card Hostnames are maintained in the corresponding Server's Device Maintenance dialog. The device will need to be reset (configuration cleared) to be able to rename or modify the Host Name and IP Address.

TesiraFORTÉ Dante

The Dante-enabled versions of TesiraFORTÉ, based on Audinate's Brooklyn II Module, allows the unit to share digital audio with other Dante-enabled devices, both from Biamp and other manufacturers. Each unit can transmit up to 32 channels of audio and receive up to 32 channels of audio using up to 16 flows in each direction.

Each input and output block of channels can be defined with between 1 and 32 channels of audio (for a total of 32 inputs x 32 outputs allocated to all blocks per unit). Each Dante channel will have an explicit name. Dante Hostnames are maintained in the corresponding Server's Device Maintenance dialog. The device will need to be reset (configuration cleared) to be able to rename or modify the Host Name and IP Address.

Audio-Technica Microphone

Up to 32 Audio-Technica Dante microphones can be associated to a DAN-1 card. 16 may be associated to a TesiraFORTÉ device. Please review the Audio-Technica Mic, Audio-Technica Mic Networking Considerations and Audio-Technica Dante Mic Hardware sections for more details on this device.

SHURE Microphone

Up to 3 SHURE MXA910 Dante microphones or 6 MXA310 Dante microphones can be associated to a DAN-1 card. One MXA910 or three MXA310 Dante microphones may be associated to a TesiraFORTÉ. Please review the SHURE Mic, SHURE Mic Networking Considerations, SHURE MXA310 Dante Mic and SHURE MXA910 Dante Mic sections for more details on SHURE's MXA series.

Attero Tech Wall Plates

Please review the Attero Tech Wall Plate, Attero Tech Wall Plate Network Considerations and the unDX2IO+-B / unDX4I-B / unD6IO-B hardware pages for more details on these devices.

Dante

Dante is a proprietary digital media networking solution, developed by Audinate and licensed by Biamp, which operates on 100Mbps and Gigabit networks using standard Internet Protocol (IP) over Ethernet. A Dante stream distributes audio plus integrated control data over the network. It allows for transporting low latency uncompressed audio over standard IP Ethernet networks with sample accurate synchronization, automatic device and channel discovery, and easy to use signal routing.

Many of the properties of the Dante streams (or channels) are configurable only through Audinate’s Dante Controller software. Most importantly, routing of audio signals from transmit to receive between devices is accomplished in Dante Controller.

WARNING

 Firmware updates and resetting of the device via Dante Controller is NOT supported. These functions must be performed through the Tesira software.

AES67 Support

Tesira 3.9 release supports use of AES67, which is a technical standard for audio over IP and audio over ethernet interoperability. AES67 is a layer 3 protocol suite and is designed to allow interoperability between a variety of IP-based audio networking systems. For Tesira, this support is specific to Dante-enabled equipment and will allow interoperability between other networking systems such as RAVENNA, Livewire and SVSi.

The Dante controller (described below) allows engaging devices that have firmware installed that supports AES67 - this is required in order to configure for AES67 mulitcast streams through the Dante controller. Note that Dante devices cannot subscribe to AES67 flows from other Dante devices. See the Dante Controller support documentation for more information on enabling AES67.

Dante Domain Manager Support

Tesira 3.11 release supports Dante Domain Manager which makes audio networking more secure, scalable and manageable. Integrators can define specific AV device groupings by room, building and site, allowing for the creation of independent Dante Domains that enable a single Dante Domain to encompass multiple network subnets.

Dante Domain Manager is available from Audinate as a virtual appliance for various hypervisors. Please review the Dante Domain Manager User Guide for more details.

Firmware Updates

Normal Dante card firmware updates will be handled with a regular Tesira firmware update that is processed through Tesira Device Manager.

If a Dante firmware update or recovery from crash is needed you will use Audinate's Firmware Update Manager software, refer to the Dante card Failsafe Recovery Section.

 

Audio

The standard bit rate for the Tesira Dante is 48kHz / 32-bit.

Dante automatically converts among the PCM word sizes when necessary. Dante won’t connect incompatible audio devices. In practice, if Dante Controller software allows a connection to be made, it should pass audio.

Dante Controller and channel routing

The Dante audio network’s signal routing must be done via Audinate's free Dante Controller software on either a Mac or PC. It can be downloaded from Audinate. 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 can conceivably come from a different Dante-enabled device. Dante supports multicasting, or fan-out on the network, 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. Additionally, 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 to predict streams and bandwidth requirements as can be done with AVB.

 

Flows: Unicast and Multicast

Each DAN-1 card can transmit up to 64 channels of audio and receive up to 64 channels of audio. A TesiraFORTÉ Dante enabled device can transmit up to 32 channels of audio and receive up to 32 channels of audio A set of channels from a particular device is encapsulated in packets called a flow. A flow is a standard container for up to 4 channels which is created automatically when you configure Dante routing. In connections to the same receiver, no new flows will be created until all four channels in the most recently created flow are filled.

If a transmitter runs out of the available flows, multicast is necessary to reduce the number of transmitted flows. 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.

Also, it’s possible for receivers to not have enough flows in special 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.

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 the minimum, because multicast flows increase the load that the switch is subjected to. Up to eight channels can be grouped into a multicast flow, further increasing their efficiency.

Finally, to help manage the multicast traffic on the network it is recommended to enable IGMP snooping on your switches.

Network Connections

The DAN-1 card connects via standard CAT-5e or higher network cabling to a network switch, same as a TesiraFORTÉ Dante enabled device. This is a separate connection from the SNC-1, SNC-2 or Control network control port on the Tesira, and requires its own cable. It can share the same network switch hardware network control port if necessary.

Unlike AVB (Audio Video Bridging) or CobraNet, Dante does not require special switch hardware, protocols, or VLANs, allowing it to operate with current “off-the-shelf” network hardware along with standard network traffic. As a rule of thumb, a separate, dedicated Dante network is recommended for high channel-count applications.

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

Note

Any switch that supports Diffserv (DSCP) QoS with strict priority and 4 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. A Gigabit interface is required for channel counts above 32 x 32 48kHz/24bit.

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.

For low channel count (<32) applications, a 100Mbps switch may be used as long as it supports proper 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 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.

If you use 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.

Single-link network limitations:

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; for example if a Gigabit port on switch A is connected to a 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 used at the same time on a Dante device. Channels are individually selectable for multicast transmission.

Device Discovery

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 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.

The secondary port found on the DAN-1 card is not to be used for daisy chaining – this is for Dante redundancy only. Dante offers a full-time redundancy option with permanent primary and secondary audio transmission. Redundancy requires a second distinct IP network. Cross-connecting the two networks will cause errors seen by Tesira as run time faults. Dante Controller must be used to identify issues in Dante streams. TesiraFORTÉ Dante enabled devices feature only 1 Ethernet port which is designed to be connected to the primary Dante network. Because there is only one Ethernet port on a TesiraFORTÉ Dante enabled device, redundancy is not supported.

Since Dante uses IP and not Layer 2 addressing, with Audinate’s Dante Netspander software installed on a qualified rack-mount server Dante digital media can be transported across up to 40 subnets and across IP routers for large scale installations.

Dante devices are connected via a network switch, which most often means a “star” topology – all devices are connected to a single central point, which minimizes the number of “hops” through which data must pass. This also avoids the scenario in which the failure of one device causes the entire “daisy chain” to break.

Because Dante works with standards based networking technology, using fiber is simple. Use a switch that supports fiber connections to send Dante data over a fiber optic cable. Ethernet is not copper or fiber based, it is independent of the cabling medium. Many organizations may have fiber already in place from other projects and this can simply be re-used on a Dante network.

Setting Tesira Dante card Network settings

The Network settings of the Dante cards can be adjusted in Device Maintenance > Network. In a SERVER or SERVER IO the Primary and Secondary interface IP address can be specified independently.

 

Selecting the Interface Status button will show the relevant settings being used.

Naming rules for Dante

In Dante, devices and audio channels are identified by names and labels which can be customized. Names can be assigned to channels while in the Tesira software and they will be offered to Dante Controller for use. 

Initially all channels will be given names in the form:

If working with the SHURE MXA Series microphones, all channels will be given names in the form <Instance Tag>_Lobe<channel number> or <Instance Tag>_Mix<channel number>, where Instance Tag is the default value when the block is created and channel number is within the block, starting with 1. The Lobe channels are between 1 and 8, depending on the number of lobes selected at the time of block creation. Also, the Mix output will be shown if the option was selected at the time of block creation.

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 Dante hostnames will be unique, following the convention TesiraServernnnnnnnn-Slotnn where the Tesira's Serial Number and Card Slot Number are appended to the string "TesiraServer".

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).

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 labelled “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.

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 “MY16-slot1”. If user attempts to rename another device to “MY16-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. A device that has been renamed with (2) appended (e.g. “MY16-slot1(2)”) will not be able to transmit audio until it is renamed. 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” where the string TesiraServer is appended by its serial number. As with the channel names, the device names can be changed to better reflect the use case associated with the device.

In Tesira inputs and outputs will be 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 cares that the Tesira DAN-1 has 64 in and 64 out available.

 

DAN-1 Card Redundancy

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

Dante redundancy requires that both the primary and secondary interfaces on any redundant card 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.

TesiraFORTÉ Dante enabled 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 is not to be used for daisy chaining devices.

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

Faults

If there is a major fault where all of the channels in a Dante block aren’t passing audio Tesira will report "One or more Dante flows inactive".

Cross-connecting primary and secondary Dante networks will cause network faults and errors.

Further diagnosis of faults requires the use of Dante Controller.

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 Master 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 Master Clock. One device is elected as the Master Clock to which other devices are synchronized. By default this selection takes place automatically, with no need to manually assign a Master Clock.

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

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

To force a specific device to become the Master Clock use the Dante Controller to set a Dante device to be "Preferred Master". If more than one device is selected as the "Preferred Master", the device with the lowest MAC address will be chosen during a clock election. Tesira will advertise its DAN-1 cards as "Preferred Master" devices by default.

If AVB cards are present in a Server they will impose their clock on the Dante network. The DAN-1 in that chassis will show “preferred master” and “slave to external word clock” in Dante Controller. Other Dante devices will be slaved to that “preferred master”. In the event a Dante device sees multiple "preferred master" devices, the Dante devices will negotiate between themselves to determine the correct "preferred master" device.

In a system with AVB and Dante cards the AVB network must provide the clock. (Tesira will negotiate this automatically.)

Dante cannot be used as a "bridging" protocol between 2 or more Tesira AVB systems.

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 Master Clock can be:

There are certain circumstances in which the automatic Master 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 Master Clock. Using the Preferred Master setting in Dante Controller, you may designate as a Master Clock a device (or devices) that is always present for the entire time that the network is required to function.

Slave to External Word Clock

A Dante device with "Slave to External Word Clock" set will use the external word clock from its host equipment to tune its onboard VCXO. A Dante device with this attribute set will become the PTP Master Clock, unless there is another Dante device present with "Preferred Master" set.

Preferred Master

Sometimes it may be necessary to force a particular device to provide the PTP Master Clock. A Dante device with "Preferred Master" set will always be chosen as the PTP Master Clock.

If a device set as a Preferred Master is added to a Tesira Dante system, and that device's Dante MAC address is lower than that of the Tesira Server, it will become the Master Clock device. Since Tesira's clock protocol requires it to be the Master Clock for the system this scenario will cause a (major) system fault. The fault can be resolved by unchecking the Preferred Master selection for the offending device.

In a redundant network, the clock synchronization protocol operates over both primary and secondary networks. Each network will have a designated PTP Master Clock; usually this will be the same device on both networks. If this is not the case (e.g. if a non-redundant device is designated Preferred Master) then one device will bridge the clock synchronization information from the primary to the secondary network, ensuring that all devices derive their clock from the same source. Redundant PTP Slave clocks will synchronize their local clocks based on information from one of the networks they are connected to. In event of a failure on one network a redundant device will continue to receive clock synchronization information over the other network.

Troubleshooting clock issues:

Supported devices are constantly monitored by Dante Controller to establish the accuracy and stability of their clock synchronization with the Dante network master clock. If a device clock is exhibiting significant instability, it becomes at risk of losing sync with the master clock, and Dante Controller can display a ‘Clock Instability Detected’ pop-up, identifying the device.

In Dante Controller a “Clock Instability Detected” popup indicates a network configuration or hardware issue that is causing inconsistent packet timing. For example:

Issue

Resolution

Energy Efficient Ethernet ('Green Ethernet') functionality is active on a switch.

EEE is a power-management system for Ethernet switches, and can easily interfere with clock synchronization. Audinate recommends that you avoid unmanaged switches with EEE functionality, and fully disable EEE on any managed switches.

There is a 100 Mb switch or link where a Gigabit connection is required.

If your devices require Gigabit connections, make sure there are no 100 Mb links or switches in the chain. Audinate recommends always using Gigabit switches for network backbones.

One or more of your switches are incorrectly configured, or are not suitable for Dante networking

Ensure that you are using switches that support QoS, and Dante traffic is properly prioritized.

Network stress from other sources.

If you are running traffic from other sources across the network, it may be causing bandwidth issues that are interfering with Dante packet timing.

Excessive multicast traffic.

Using multicast flows where they are not actually necessary can overload a network, particularly if there are any 100Mbps switches or links present. Consider switching some subscriptions to unicast to take the pressure off the slower nodes in your network. The Dante multicast audio bandwidth for the network is displayed in the Dante Controller menu bar.

As a rule of thumb, total bandwidth utilization (including multicast and unicast) on any given link should not exceed 70% of the supported bandwidth for that link. Utilization above 70% of supported bandwidth can adversely impact clock synchronization (especially if there is also non-Dante traffic on the network).

It is also recommended (for this particular issue, and in general) that you ensure all your Dante devices are using the latest firmware, and that you are using the latest version of Dante Controller.

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.

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.

Latency in a Dante system is deterministic and guaranteed. Receivers that are listening to the same audio transmitter using the same latency value are guaranteed to be sample aligned. A Dante receiver introduces an additional latency before playing out audio to account for delay variation in the network or end device.

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

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.

Dante DSCP / Diffserv priority values when configuring QoS

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.

Priority

Usage

DSCP Label

Hex

Decimal

Binary

High

Time critical PTP events

CS7

0x38

56

111000

Medium

Audio, PTP

EF

0x2E

46

101110

Low

(reserved)

CS1

0x08

8

001000

None

Other traffic

BestEffort

0x00

0

000000

Dante Virtual Soundcard Firewall Configuration

The Dante Virtual Soundcard communicates over UDP using the following ports: