Issue: Clicks and Pops
You’ve set up a Dante network because you’ve heard about how great the audio is; lossless, low latency, and perfectly synchronized across all your devices. So you plug it in, set it up and the audio is full of stutters, popping noises and clicks. What went wrong?
The answer is that clocking has gone wrong and must be fixed. Let’s look at how Dante clocking works, and how you can easily overcome problems that you may encounter.
How Dante clocking works: Dante uses Precision Time Protocol, or PTP. PTP is a standardsbased method of achieving very tight time synchronization of devices on a network.
On a network, the exact time it takes to traverse from one device to another varies depending upon network topography. PTP overcomes this problem by relying upon a single leader clock and then calculating any time differences between devices, allowing all devices on a network to operate in tandem. Dante devices then generate their own clocks based upon this time reference. If there is a momentary failure of sync to the PTP leader, we hear the pops and clicks of lost audio samples.
So, how do all the devices “see” a PTP clock leader at once? The answer is multicasting, which allows the PTP leader to send synchronization messages to all Dante devices at once. There lies much of our problem, too.
Multicast failures. Anything that might interrupt multicasting on a Dante network will cause clocking to fail, either completely or partially. A complete failure causes Dante to go silent, but a partial failure may result in the “pops and clicks” that we hear as the audio samples drop out during playback.
Bad switch configuration #1: Multicast not properly enabled. A network switch that is not properly configured to handle multicast traffic can certainly cause clock failures on a Dante system. Note that unmanaged switches always pass all multicast, but that managed switches contain settings that may block or limit multicast traffic. Consult your switch configuration documentation to address this issue.
Bad switch configuration #2: Energy Efficient Ethernet. Many newer switches employ energy saving features dubbed “Energy Efficient Ethernet”. Unfortunately, the automatic port-closing methods used often cause problems for devices that need to be always available, such as a PTP clock leader. Avoid switches with this feature or disable this feature if possible.
Bad switch configuration #3: Poor IGMP snooping configuration. Many managed switches contain a vital feature called IGMP, or Internet Group Management Protocol. This feature allows an administrator to smartly manage multicast traffic so that it goes only to devices that request it. Unfortunately, this configuration can be difficult on some switches, and may result in a loss of PTP traffic. Consult the switch manufacturer for advice on proper setup of IGMP.
Bad switch configuration #4: Different switch brands all using IGMP together. While IGMP is based upon standards, specific implementations vary from one manufacturer to another. Mixing different brands of network switches on a single network with IGMP can produce some unexpected results, as the switches may not agree about what to do with IGMP traffic. Again, the result is a loss of PTP clock sync and you’ve got pops and clicks. Most networking experts recommend using the same vendor for all switches on a system to avoid this issue.
Mismatched IGMP versions (Apple computers). Networking standards are, alas, not entirely standard. The engineers at Apple interpret the standards to distinguish between variations of IGMP versions, while other vendors do not. The result can be a loss of multicast traffic when using Dante software on the Mac, resulting in clock failure and there goes your audio.
Fortunately, this issue only affects the built-in Ethernet ports on Apple Mac computers. Using any sort of Ethernet adaptor (USB or Thunderbolt) eliminates this issue and allows PTP to function as expected when using software products such as Dante Virtual Soundcard.
Console clock confusion. There is one clock failure condition that doesn’t involve multicast, and that is the improper setup of internal clocks on products such as mixing consoles or DSPs.
If one is using Dante on a mixing console alongside non-networked digital audio products such as MADI, a common clock must be used that can address both simultaneously. To accomplish this, one may choose to 1) use the internal clock of the console for everything, or 2) use the Dante clock for everything.
Consoles that employ Dante contain settings that allow them to use the Dante clock instead of their internal reference. Conversely, Dante Controller contains settings that allow the internal clock of a console to act as the time reference for the network. As long as the console settings and Dante Controller agree, the system will work fine. But if they are mismatched, devices may see very erratic clocking behavior.
Example: a mixing console is configured to use its internal clock. The Dante interface is configured to use the Dante PTP clock. Both clocks may be very close in time, but they are not the same. The result is intermittent audio as the clocks drift in and out of temporary sync.
The solution is fortunately simple. Check the mixing console settings and choose a clock source, Dante or internal. In Dante Controller, set the parameter “Enable Sync to External” to match the console settings; enable the parameter to use the console’s clock, or disable the parameter to use Dante clocking.
Issue: Nothing Shows Up
So, you’ve just setup your Dante system. You’ve plugged Dante-enabled devices into network switches, perhaps you’ve made some adjustments to the switches, and then you fire up Dante Controller and see… nothing. Or perhaps you see some devices, but nothing works. That’s not very plug and play. What’s happening?
Let’s learn a bit about Dante Automatic Discovery and figure this out.
Dante Automatic Discovery basics: Dante is designed so that, under most conditions, simply connecting Dante devices to the same network as a PC running Dante Controller will result in those devices appearing in Dante Controller. To accomplish this, each Dante device must “announce” its existence on the network so that any copies of Dante Controller and any other Dante devices can “hear” it.
In order to do this, Dante devices employ multicast networking. You’ve almost certainly heard the term, and it is at the heart of this problem.
There are 3 fundamental types of network traffic:
- Unicast – one to one private communication between devices, like a letter sent to an individual.
- Broadcast – one to many communication that all devices must receive, like junk mail addressed to “occupant”.
- Multicast – one to many communication sent from a device only to devices that request it, like a newsletter sent to many recipients who have signed up for it.
Because a new Dante device cannot “know” where Dante Controller is, using broadcast or multicast makes sense as a discovery method. The device sends a message addressed to “everyone” and waits for a reply. Multicast is much better behaved than indiscriminate broadcast, and so that is what Dante uses. Dante Controller listens for multicast traffic from Dante devices so that it can display and use them.
The Secret Sauce in the Switch: Just as subscribers to a newsletter are part of a list somewhere, so are recipients of multicast traffic. When a multicast message is sent, devices that want that traffic ask for it and become part of a group membership list that resides on the network switch. When multicast messages arrive at the switch, it checks those group lists to see which devices have requested the data. This group membership technology is referred to as IGMP (Internet Group Management Protocol).
When a switch groups a data sender with a bunch of recipients, that process is called snooping. When there are multiple switches on a network, they must all agree about these multicast groups, and so must coordinate their IGMP behavior. If they don’t, some traffic won’t go to where it’s supposed to.
Here’s where the Dante discovery problems arise.
Dante discovery errors are multicast errors: When Dante devices fail to appear, or appear and are unusable, this is most frequently an issue with multicast traffic not being accessible where it is needed. What can cause this to happen?
- Improper switch configuration. IGMP setups can be tricky, and inexperienced users may inadvertently configure IGMP so that it isn’t working correctly, preventing multicast traffic from reaching Dante Controller. This is the most common case we encounter. We recommended testing with all multicast limitations disabled.
- Multiple switches from different brands. For IGMP to work, all switches must be able to coordinate IGMP group information. Unfortunately, when using switches from different makers, this cannot be guaranteed. Consult with the makers of your switches for more information. Using a consistent brand of switches often makes this a non-issue.
- Multicast version confusion. There are several versions of the multicast specifications, and some interpretations can prevent older technology from working with newer devices. A good example of this are the built-in Ethernet ports on Apple computers, which use multicast v3 and will not work well with devices using multicast v2. Note: this issue is easily overcome by using external Ethernet adapters in lieu of built-in connectors.
- Devices and computer running Dante Controller are not on the same LAN. If you have a network with multiple subnets, you have multiple LANs. Multicast traffic generally cannot pass between subnets or LANs, and so all Dante devices must be on a single LAN to work. If you’re not routing between subnets, then you must ensure that all IP addresses are unique and part of a correctly defined set. This is usually done automatically by using DHCP, but can be a source of Dante discovery failure when manually assigned IP addresses are employed. Note: Dante Domain Manager allows you to pass Dante traffic between subnets.
