One of the things that took me a while to really appreciate about Dante is that getting the audio from one device to another is only part of the problem. With traditional audio systems, I never really had to think about whether all my equipment was in sync. If I plugged a microphone into a DSP and sent the audio to an amplifier, the signal would follow a physical path from one piece of equipment to the next. As long as everything was connected and configured correctly, there wasn’t much reason to worry about whether the microphone and DSP agreed on the time. Once audio starts traveling across a network, that changes.
Now I can have dozens of devices sending and receiving audio over the same network, and each device has its own internal clock. Those clocks aren’t perfect, and they don’t naturally stay synchronized with each other. That might not sound like a big deal at first, but when you’re dealing with digital audio, even small timing differences can eventually become a problem. The devices need to agree on when a sample should be played, and they need a common reference to do so. That’s where PTP, or Precision Time Protocol, comes in.
I remember hearing about PTP when I was learning Dante, what feels like a lifetime ago, and thinking it was just another one of those networking terms I needed to remember because the manufacturer said it was important. I knew Dante used PTP, there was something called a clock leader, and Dante Controller would show me which device was leading the network. What I didn’t immediately understand was why the system needed a clock in the first place. If the audio packets were getting from the transmitter to the receiver, wasn’t that enough?
Why the clock matters
It turns out it isn’t. Think about a band playing together. Every musician can have the exact same sheet music, but they still need to agree on the tempo. If the drummer starts playing slightly faster than the guitarist, it doesn’t take long before they’re no longer playing together. Networked audio has a similar problem. Every Dante device has its own clock, and those clocks must be synchronized closely enough for the devices to keep their audio samples aligned. PTP gives them that common reference.
In a Dante network, one device becomes the clock leader, and the other Dante devices synchronize their clocks to it. The clock leader isn’t necessarily something I manually choose. Dante uses an election process to determine which device should take that role based on the devices available on the network and their clock capabilities So Dante Controller uses its best master clock algorithm and says, “You’re the one keeping time.” If the current leader disappears, another appropriate device can take over.
Once the network has that reference, the other devices can synchronize their clocks to it. The timing information is also separate from the actual audio. The Dante network is moving audio packets from transmitter to receiver while ensuring the devices agree on time. That distinction is important because it helps explain why having a healthy audio subscription doesn’t necessarily mean the entire Dante system is healthy. That doesn’t mean every audio packet magically arrives at exactly the same instant, though. The packets are still traveling across a network, and some may arrive slightly earlier or later than others due to events occurring between the transmitter and receiver. That’s where buffering and latency come into play.
The receiver uses a buffer to hold incoming audio long enough to compensate for some of that variation. When I set a Dante latency value, I’m not telling the system how much delay I want added to the audio. Instead, I’m giving the receiving device time to receive and process the packets before they need to be played. If packets don’t arrive at perfectly consistent intervals, the receiver needs sufficient information and time to handle that variation. A network can have plenty of bandwidth and still experience jitter, packet loss, or latency. That’s why “the network has plenty of bandwidth” isn’t really enough of an answer when troubleshooting real-time audio.
When Dante meets AES67
The more interesting part for me is what happens when we start comparing Dante to AES67. I’ve heard AES67 described as another version of Dante, but that’s not entirely accurate. Dante is a complete networked audio system developed by Audinate. It includes discovery, routing, clocking, device management, and audio transport. AES67, on the other hand, is an interoperability standard that allows different networked audio technologies to exchange audio using common protocols.
That distinction becomes especially noticeable when I have to connect equipment from different manufacturers. With a Dante-to-Dante system, the workflow is usually simple. I open Dante Controller, find the transmitter and receiver, make the subscription, and Dante handles much of the work behind the scenes. Once I start connecting a Dante system to an AES67 device, the process can depend more on how each manufacturer has implemented the standard. I may need to work with stream information such as the multicast address, UDP port, sample rate, or channel count before the receiving device knows exactly what it is supposed to subscribe to.
That’s where understanding what’s happening under the hood of the software becomes important. If the audio doesn’t show up, I can’t necessarily assume the source or receiver is the problem. I have to start looking at whether the stream parameters match, whether the devices are synchronized to the same PTP clock domain, and whether the network is correctly handling the traffic between them. If multicast is involved, IGMP behavior becomes part of the conversation as well. The audio may be fully compatible between the two devices, but if they don’t agree on how the stream is configured or transported, I still won’t hear any audio.
The clocking piece is especially important because AES67 also relies on PTP for synchronization. In other words, even though Dante and AES67 are different technologies, they share some of the same fundamental principles. They both need the network to provide accurate timing, predictable packet delivery, and appropriate handling of real-time media.
This is also why network design matters so much. If I’m deploying a Dante system across a campus, I’m not just asking whether my switches support Dante. I’m thinking about multicast behavior, IGMP snooping, the IGMP querier, QoS, VLAN configuration, uplinks, latency, and where the Layer 3 boundaries are located. I’m also thinking about whether I’m staying entirely within the Dante environment or whether I need to exchange audio with another technology using AES67.
I’ve worked on projects where the audio side seemed straightforward until we started discussing how different systems needed to exchange audio. That’s when terms like Dante, AES67, multicast, PTP, and RTP start showing up in the same conversation, and suddenly “just networked audio” becomes a much more complicated engineering problem.
The more I work with Dante, the more I realize that the subscription I make in Dante Controller is only part of what I can see. Underneath that simple click is a network moving RTP-based media, devices synchronizing their clocks, switches forwarding packets, buffers managing packet timing, and systems constantly maintaining the timing necessary to turn those packets back into audio.
That’s what makes networked audio so interesting to me. The person standing in the classroom doesn’t see any of it. They talk into a microphone and hear their voice come out of the speakers. They don’t know which device is the clock leader, what the Dante latency is set to, whether the audio is using multicast, or whether the system is exchanging audio with an AES67 endpoint. And honestly, that’s exactly how it should be. But when you’re the person responsible for designing and troubleshooting the system, you need to know what’s happening underneath it. Once you put audio on a network, managing time takes on a whole new meaning.
