You’ve setup a Dante network because you’ve heard about how great the audio is; loss-less, 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 standards-based 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 de-pending upon network topography. PTP overcomes this problem by relying upon asin-gle 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 Ether-net”. 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 Manage-ment 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 manufac-turer to another. Mixing different brands of network switches on a single network with IGMP can product 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 al-lows 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 im-proper 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 every-thing, 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.

That’s all for now. We hope you enjoy a day free of annoying noises!