Skip to main content
Biamp Systems

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.  It allows for transporting low-latency, uncompressed audio over standard IP networks with sample accurate synchronization, automatic device and channel discovery, and easy-to-use signal routing.  

The Dante DAN-1 card, based on Audinate's Brooklyn II Module, allows Server-class Tesira 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. (A flow may be considered roughly analogous to a bundle in CobraNet or a stream in AVB. The flow is the container encapsulating the channels. See Flows)

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 managed in the corresponding Tesira Server's Device Maintenance dialog.

The Tesira Server-IO can accept up to (2) DAN-1 cards per chassis. The Tesira Server can support (1) DAN-1 per chassis. Dante is not available Tesira Expanders.

DAN-1 card.PNG

 

The TesiraFORTÉ DAN, based on Audinate's Brooklyn II Module, can transmit up to 32 channels of audio and receive up to 32 channels of audio using up to 16 flows in each direction.

TesiraFORTÉ DAN devices do not support redundancy must be connected to the primary network only.

The TesiraFORTÉ DAN is available as a TesiraFORTÉ DAN AI, TesiraFORTÉ DAN CI, TesiraFORTÉ DAN TI, and TesiraFORTÉ DAN VI.

Please note this article is a comprehensive reference on Biamp's implementation of Dante, the DAN-1 card and TesiraFORTÉ DAN.

 

Dante overview

Many of the properties of the Dante flows (or channels) are configurable only through Audinate’s Dante Controller software. Most importantly, routing of audio signals is accomplished in Dante Controller.

The standard bit rate for the Tesira and the DAN-1 is 48kHz / 24-bit. This cannot be altered.

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.

Channel naming and routing

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

Once online, routing and channel assignment can only be done in Dante Controller software.

Warning - Users are strongly discouraged from renaming transmit and receive nodes while online using Dante Controller as the updated names may not be reliably transmitted back to the Tesira software.

IO blocks.png

Dante Controller software

Dante Controller screenshot.PNGThe Dante audio network’s signal routing must be done via Dante Controller software on either a Mac or PC. 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.

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 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 made to the same receiver, no new flows will be created until all four channels in the most recently created flow are filled. The DAN-1 card can have 32 x 32 simultaneous flows, with a total of 64 x 64 channels.

A flow is a UDP / IP data packet containing up to 4 channels routed to 1 device, or up to 8 channels of multicast data. A single packet may contain multiple audio samples for each channel.

If a transmitter runs out of the available flows, use of multicast flows may be 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 for the transmitter.

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

Naming rules for Dante

In Dante, devices and audio channels are identified by names and labels that can be customized. Names can be assigned to channels while offline in the Tesira software and they will be offered to Dante Controller for use. It is strongly recommended that naming is done while offline in Tesira software only, to protect against names being lost or corrupted in the event of a power cycle or reboot of the Tesira device.

Initially, all 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 DAN-1 hostnames will be unique, 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). 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 should be in an unconfigured state when renaming the DAN-1.

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.

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.

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

Dante Channel Labelling IO.PNG

Networking details

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

As a rule of thumb, a separate, dedicated Dante network is recommended for critical, high channel-count applications.

The DAN-1 Dante network should not share the same network hardware as AVB or CobraNet devices.

If it is unavoidable to share network hardware, each network protocol (Dante, AVB, CobraNet) should be placed into its own VLAN, and there must be clearly mapped-out bandwidth requirements for each protocol's VLAN.

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.

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.

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

Bandwidth

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

Network speed Channel Limitations
1000Mbps (Gigabit) 512 x 512 48kHz/24bit audio channels can be sent over a single link, giving a total of 1024 bi-directional channels. For 96kHz/24bit audio the channel capacity is halved.
100Mbps (Fast Ethernet) 48 x 48 48kHz/24bit audio channels can be sent over a single link, giving a total of 96 bi-directional channels. For 96kHz/24bit audio the channel capacity is halved. It is recommended that Fast Ethernet links not exceed 32 channels.

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 for one or both of the DAN-1 Ethernet ports using Tesira software. Note that IP address edits should be done with the Tesira in an unconfigured state (no system file loaded). 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 is not to be used for daisy chaining devices.

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.

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
 

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. 

Clocking and latency

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 you would normally 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.

Because Tesira is capable of combining and synchronizing multiple network audio protocols, the Preferred Master flag of a Tesira device's Dante interface cannot be set using Dante Controller. A Tesira device will set its Preferred Master 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.

The clock 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 Master” and “Enable sync to external" word clock flags set, with the AVB card providing that external word clock source. Other Dante devices will be slaved to that “Preferred Master”.  
  • If the Dante network has been specified as the Clock Master 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 Master” 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 Master" state. In the event a Dante network has multiple "Preferred Master" devices, the Dante devices will negotiate between themselves to determine the correct "Preferred Master" device. The Dante device with the highest quality Dante chipset and lowest MAC address will become the "Preferred Master". 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 master 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 Master" flag then no other devices on the network should be set to "Preferred Master".
  • 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 Master then the synced DAN-1 will be elected clock master. In this configuration a 3rd party Dante device on the network should be defined as "Preferred Master". 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 Master” 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.

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

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:

  • 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 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 more than one device has "Preferred Master" set, the device with the lowest MAC address will be chosen.

Tesira enables "Preferred Master" status by default when equipped with both AVB and Dante cards. It will not be enabled if Tesira is equipped with only Dante cards. It will not be enabled if Tesira is equipped with CobraNet and Dante cards.

Tesira with AVB and Dante: 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.

Tesira with Dante only, or CobraNet and Dante: 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. Tesira cannot be the Preferred Master if the frame is not equipped with an AVB card. The Preferred Master checkbox in Dante Controller will clear itself if it is selected.

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.

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.

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

Latency Settings.pngIn 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. 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.

Firmware Update Manager

The Tesira's DAN-1 cards run Dante firmware provided by Biamp. If Dante firmware updates are required they are made using Biamp Tesira software's Device Maintenance > Update Firmware tool. 

If your system is up to date with the latest Tesira firmware, then your DAN-1 card is up to date with the latest supported Dante firmware.

  • Was this article helpful?