Dante Level I–III

Introduction

One network cable, two hundred channels of audio, and a patch you change by clicking. That is the promise, and it is real — as long as the network underneath it was built for the job and somebody understands the clock.

This book is that understanding. What Dante actually does, how audio flows across a network, what a subscription is, why the clock matters more than anything else, what a switch has to be told, and what to do in the ten minutes when a device will not appear and a band is waiting.

What this book covers

• What Dante is, how audio flows, and what a subscription really is.
• Routing in the controller, naming devices and channels, and unicast against multicast.
• The clock: PTP, leaders and followers, and reading clock status before guessing.
• Sample rate, bit depth and latency — settings, not symptoms.
• Switches: gigabit, quality of service, IGMP snooping, VLANs and the features to turn off.

• Redundancy, computers on a Dante network, Domain Manager and presets.
• AES67 and talking to systems that are not Dante.
• Building a small system end to end, and documenting it.
• Troubleshooting: a device that will not appear, a subscription that will not complete, dropouts and clock faults.
• The certification levels, tour against install, and where the skill leads.

Who this is for

Audio technicians who now have a network in the signal path, video and IT people asked to host one, and anybody working towards the certification levels. It assumes Networking Basics for switches, addresses and VLANs, and Audio Basics for what the signal is.

How to Use This Book

Read it once, then build something. The chapters follow a system: what it is, how it routes, what times it, what carries it, how it is made reliable, and what to do when it is not.

Build a two-device system

Almost everything here can be practised with two Dante devices, or one device and a laptop running a virtual soundcard, on a single switch. Route a channel, name everything, change the clock leader, set latency, then break it deliberately and watch what the controller says.

Keep a notebook

Write down the device names you gave every unit and why, the sample rate and latency the system is running, which subscriptions you made, which switch port each device landed on, and which device is the clock leader. A Dante network that works looks identical to one that is about to fail, and the notebook is the difference between finding the change and hunting for it.

A note on the words

The vocabulary is precise and often misused. A flow is not a subscription; a device is not a channel; the leader clock is still called the master clock by most of the industry. This book uses the words the controller uses and names the alternatives where they matter.

A note on safety

Networked audio is not dangerous in itself, but it lives in racks near power, under rigs, and in venues where other people's systems are running. Nothing here qualifies you to do electrical work or to alter a building's network. It teaches you to work within your training, to ask before touching somebody else's infrastructure, and to protect your hearing when a fault arrives as a very loud noise.

Where this book sits

This book assumes Networking Basics for switches, addresses and VLANs, and Audio Basics for what the signal is. It does not assume you have ever opened Dante Controller.

What pairs with this

• Networking Basics — the switches, addressing and VLANs this book depends on
• AV Documentation & System Design Basics — documenting a system somebody else has to maintain

Where it leads

These are not steps in an order. Take whichever one fits.

• AV Networking Intermediate — larger networks, deeper diagnostics and design work
• A2 & Stage Audio Fundamentals — the stage end of every system you will patch
• Live Sound Production — the shows these networks are built for

What Dante Is

Dante is audio carried as data on an ordinary network, routed in software. That one sentence contains everything that makes it powerful and everything that makes it fail: the audio is fine, and the network is now part of the signal path.

Networked audio: many channels of pristine audio over one ordinary network cable.

Networked audio with Dante

Dante is a technology for carrying professional audio over standard computer networks — many channels of high-quality, low-latency audio travelling as data over the same kind of network you learned about in Networking Basics. Instead of running a separate cable for each audio channel, a Dante system carries dozens or hundreds of channels over network cabling, and any input can be routed to any output in software. Dante has become the dominant networked-audio standard in professional AV, found in consoles, processors, amplifiers, microphones, and more. It sits exactly at the intersection of audio and networking, which is why both foundations matter here.

The appeal is the same as AV-over-IP generally: scale (many channels on one network), flexibility (route any source to any destination in software, reconfigure without rewiring), and using standard network infrastructure. For audio specifically, Dante's wide adoption means devices from many manufacturers interoperate over Dante, making it a common language for connecting pro audio gear. Understanding Dante as networked audio — audio as data on a network, routed in software — is the foundation of this book.

A single network cable carries many channels in both directions, and any input on any device can be sent to any output on any other, by clicking. A patch that used to be a wall of cable becomes a grid on a screen that changes in seconds.

The trade-off is that the network becomes show-critical. Everything that is true of a network — switches, addressing, priority, timing — is now true of your audio system, and the parts of networking that never mattered before matter a great deal now.

How Dante audio flows

In a Dante system, audio flows as data over the network: a Dante-enabled device (a console, an interface, a mic) puts its audio onto the network; the audio travels over network switches as data; and another Dante device receives the channels it is routed and outputs them. Routing — deciding which source channels go to which destinations — is done in software (using Dante's controller application), not by physical patching. This software routing is a defining feature: you patch audio by clicking connections in software, and can reroute instantly without touching a cable. Source device, network, routing, destination device is the shape of every Dante system.

This builds directly on Networking Basics: Dante devices have network addresses, connect to switches, and send audio data across the network, so the networking fundamentals (switches, IP, and for larger systems VLANs and QoS) apply. And it builds on Audio Basics: the audio is still the signals you understand, now carried as network data. Dante is where your audio and networking knowledge combine into a powerful, modern way of moving sound, which is why it is so widely used and worth certifying in.

A transmitter puts channels onto the network. A receiver takes the channels it has been told to take. Between them the network carries flows — bundles of channels — and the subscription is the instruction that says a particular receiver channel wants a particular transmitter channel.

Routing does not move audio through the controller. The controller tells devices what to subscribe to; the audio then travels device to device across the switches. Turn the controller off and the system keeps running.

What a subscription actually is

It is a standing request: this receive channel wants that transmit channel, from that device. The receiving device asks for it, the transmitting device sends it, and the subscription's status is the single most useful diagnostic in the system.

A green tick means it is working. Anything else — a warning, a cross, a colour — has a short list of causes: the device is gone, the clock is wrong, the sample rates do not match, the latency is too short, or the network will not carry it.

Where Dante turns up

Consoles, stage boxes, amplifiers, processors, microphones, conferencing systems, broadcast, installed venues, recording rigs and laptops. It has become the common language between manufacturers who agree on very little else.

That ubiquity is why the skill is worth having: on most jobs, whatever the brands, somebody has to make the network part work, and it is usually the person who understood it first.

What Dante does not change

Gain structure, microphone technique, room acoustics and mix decisions are exactly as they were. The network carries the audio faithfully; it does not improve it, and a badly gained input arrives badly gained at two hundred destinations.

Nor does it remove the analogue edges. Every Dante system starts and ends at a converter, and those converters are where the sound is still decided.

The words, used precisely

The controller uses these exactly; so should you.

On the job

A stage box, a console and a recording laptop sit on one switch. The engineer routes thirty-two channels to the console and the same thirty-two to the laptop, in about a minute, and then changes two of them during the interval without touching a cable. The same job in copper is two multicores and a splitter.

What goes wrong

Practice it

With any two Dante devices, or one device and a laptop.

Routing & Setting Up Dante

The controller is a grid: transmitters down one side, receivers across the top, and a tick where they meet. Everything else in the application exists to tell you why a tick is not there.

The power of Dante is routing audio in software — and it starts with a clean network.

Routing in software

The signature Dante skill is routing audio using the Dante controller software, which shows all the Dante devices on the network and their channels and lets you connect any source channel to any destination by making connections in software. Want a microphone's channel to reach a particular speaker or recorder? You route it in the controller — no repatching cables. This software routing makes Dante systems extraordinarily flexible: a large, complex audio routing that would be a nightmare of cables becomes a set of connections you manage on screen, and can change in seconds. Mastering this routing is central to working with Dante.

Devices on a Dante network are identified by names, and a key practice is naming devices and channels clearly so the routing is understandable — much like organising a patch. A well-named, well-routed Dante system is easy to work with; a poorly-organised one is confusing. The Dante controller is your window into the whole networked-audio system, and using it to route and manage audio is the everyday craft of Dante.

Open the grid, find the transmitting device's channel and the receiving device's channel, click where they cross, and wait for the tick. Do it again for every channel, or use the device view to subscribe in bulk.

Then check the ticks rather than trusting the clicks. A subscription that did not complete looks almost the same as one that did, from across a room, and the difference is the whole show.

Setting up a Dante network

Setting up Dante combines audio and networking practice: connect the Dante devices to a network (switches and cabling, per Networking Basics), ensure they are on the network correctly (addressing), and use the controller to route the audio. For small systems this is straightforward; for larger ones, the networking matters more (proper switches, and for big systems the segmentation and quality-of-service that AV-over-IP needs, since Dante audio is timing-sensitive network traffic). A Dante system is an audio system running on a network, so it needs both set up correctly.

A crucial Dante concept is clocking: all devices on a Dante network must share a common clock (one device acts as the clock leader, the others follow) so the audio stays synchronised. Clocking is handled largely automatically, but understanding that synchronised clocking is essential — and is a common source of issues if disrupted — is important. Setting up Dante well means a sound network, devices correctly on it, clean clocking, and clear routing. Get those right and Dante delivers its flexible, multichannel audio reliably.

One switch is a system; several switches is a network. Use gigabit throughout, keep Dante off shared office infrastructure where you can, and if you cannot, put it on its own VLAN with priority.

Addressing looks after itself on a simple system — devices will give themselves addresses and find each other — and on larger or installed systems it is set deliberately and written down, like everything else that somebody will have to maintain.

Naming, before routing

Name every device for what it is and where it is — stage-left box, monitor-console, broadcast-rack — and label channels for what is on them. Do it before routing, because the grid is unreadable when every device is called by its model and serial number.

A naming scheme that sorts sensibly is worth ten minutes: a prefix by location or department, then a number. In a forty-device system it is the difference between finding a channel and hunting for it.

Unicast and multicast

By default a flow is unicast: sent from one device to one other. If three receivers want the same channels, three copies cross the network. Multicast sends one copy that many receivers can take, which saves bandwidth when many devices want the same thing.

Multicast costs switch configuration: without IGMP snooping the switch sends multicast everywhere, and a busy multicast system without snooping will flood a network until it stops working.

Channel counts and device configuration

Each device has a number of channels it can transmit and receive, sometimes configurable. Changing it usually restarts the device, so it is done at setup rather than during a show.

Check the counts against what the show needs before the day. Discovering that a box does sixteen channels and the show wants thirty-two is a purchasing problem, not a routing one.

Presets: saving the system

The controller can save the whole configuration — names, routing, device settings — and apply it again. That is how a touring rig arrives pre-configured, and how an installed system is restored after a device is replaced.

Save a preset once the system works, save another after every significant change, and keep them with the show file. Rebuilding two hundred subscriptions by hand is an afternoon; restoring them is a minute.

Reading the grid

The controller tells you what is wrong; most people look at it and see only ticks.

How to do it

1. Connect every device to one gigabit switch, with nothing else on it.
2. Open the controller and confirm every device appears.
3. Name every device and label channels before routing anything.
4. Set the sample rate the same on every device.
5. Choose a clock leader and set it as preferred.
6. Route the channels, working in device order, not at random.
7. Check every subscription has a tick, and listen to a few.
8. Save a preset and write down the addresses and names.

What goes wrong

Practice it

On a small system of three or more devices.

The Hardware You Will Meet

Dante is a way of carrying audio, and it arrives inside other people's equipment. Knowing what those boxes are called, and which ones dominate real systems, is the difference between following a conversation on site and nodding through one.

Stage boxes and interfaces

The commonest Dante device on a live job is a box of microphone inputs and line outputs with a network port on the back. Yamaha's Rio and Tio boxes — a Yamaha Rio3224-D under a great many touring and installed systems; Allen & Heath, DiGiCo and Midas all supply their own for their consoles; Focusrite's RedNet range, the Focusrite RedNet D64R among them, and its Red interfaces are the common answer where a recording rig meets a stage.

For small jobs the same thing shrinks: a two- or four-channel interface that puts a laptop or a pair of microphones on the network. Audinate's own AVIO adaptors are the smallest of all — a dongle that turns a single analogue, AES or USB connection into a Dante device, and the quickest way to put something onto a network that has no business being there.

Consoles and processors

Most live consoles reach Dante through a card or a module rather than natively: Yamaha's CL, QL and Rivage desks, Allen & Heath's dLive and SQ with a Dante option — an Allen & Heath dLive S7000 is a common sight, DiGiCo through its optical or network options, Midas and Behringer through their expansion slots. The card is a line item and it is frequently the thing that is missing on the day.

In installed work the processor is usually the centre: Q-SYS cores, Biamp Tesira — the Biamp Tesira SERVER at the large end — BSS Soundweb and Symetrix all speak Dante, and in a conference room or a campus the DSP rather than a console is what the whole system routes through.

Microphones, ceiling arrays and conferencing

Shure's ceiling and table arrays put Dante at the microphone itself, which is why so many meeting rooms are Dante rooms without anybody calling them that. Sennheiser's ceiling microphone does the same, and both are routinely paired with a Q-SYS or Biamp processor.

Wireless systems join the same way: Shure's Axient and ULX-D receivers — a Shure Axient Digital AD4Q is four channels in one rack space, Sennheiser's digital systems and others put their channels straight onto the network, so a rack of receivers becomes a rack with one network cable leaving it rather than a loom of analogue.

Amplifiers, loudspeakers and the far end

At the other end of the system the amplifier takes Dante directly: Powersoft, Lab.gruppen, Crown, QSC and d&b amplifiers all accept it, a Powersoft X4 being a familiar example, and self-powered loudspeakers from L-Acoustics, d&b and Meyer increasingly do too.

This is the part that changes how a system is built. When the amplifier is on the network, the analogue run is the last few metres from amplifier to driver, and everything upstream of it is one cable and a routing decision.

Computers, recorders and the small stuff

A computer joins through Dante Virtual Soundcard, which turns it into a device with up to sixty-four channels, or through Dante Via, which puts individual applications on the network. Multitrack recorders and playback machines take Dante natively or through a card.

And then the small stuff that keeps a rig alive: AVIO adaptors, a spare interface, a small managed switch of your own, and the laptop with Dante Controller on it that is, on most jobs, the only way anybody can see what the system is doing.

Why the names matter

Not because any of them is the subject — the subject is what they all do. But a technician who can say "the Rio is on the stage, the Q-SYS core is in the rack and the receivers are on the same switch" is describing a system; one who says "there's a box on the stage" is describing a photograph of one.

Specialise and it matters more. A theatre sound department, a corporate integrator and a broadcast facility each have a short list of gear that dominates their world, and knowing that list is most of sounding like somebody who has done the job before.

Where Dante turns up, by kind of device

Names change with the decade; the categories do not.

On the job

A corporate ballroom: Shure ceiling arrays into a Q-SYS core, a Yamaha console on a Dante card for the band, Powersoft amplifiers on the same network, and a laptop running Virtual Soundcard for the recording. One switch, one clock, four manufacturers, and nothing analogue between the ceiling and the amplifier.

What goes wrong

Practice it

Take a system you have worked on, or a room you can visit.

The Clock

Everything in a Dante system is timed by one clock. Not roughly — to a fraction of a microsecond, agreed across every device by a protocol running on the same network as the audio. When the clock is unhappy, the symptoms look like anything except a clock problem.

Why one clock

Digital audio is samples taken at exact intervals. If two devices disagree about how long a second is, one of them eventually has a sample too many or too few, and you hear a click, a glitch or a dropout.

So one device is elected the leader and every other device follows it. That election, and the accuracy of what follows, is handled by PTP, a protocol whose entire job is making a network agree what time it is.

Leaders, followers and preference

Devices elect a leader automatically, using their capabilities and identifiers. You can mark one or more devices as preferred, which is normal practice: choose something central, permanently powered and not likely to be unplugged mid-show.

Do not make a laptop the clock leader. It sleeps, it gets carried away for a phone call, and its network port turns itself off to save power. A stage box or a console is a better citizen.

Reading clock status

The controller shows, for every device, whether it is leader or follower, how well it is locked, and whether it has had trouble recently. That screen answers questions people otherwise spend an hour guessing at.

Look at it before anything else when audio is glitching. A system with clock warnings is a system whose audio symptoms are explained, and chasing the audio path first is wasted time.

What breaks a clock

• Energy-saving features on a switch, which put ports to sleep between packets.
• Switches that do not handle priority, so clock messages queue behind audio.
• A leader that is a laptop, or that keeps being unplugged.
• Two networks bridged accidentally, so two clock domains meet.
• Wireless anywhere in the path.
• A badly behaved device flooding the network.

Sample rate and bit depth

Every device in a system runs at the same sample rate — usually 48 kHz — and devices at different rates cannot subscribe to each other. It is a setup decision, changed with the show stopped, because changing it restarts devices.

Bit depth matters less in practice but should be consistent. Where a system has to run at a film or broadcast rate, decide it once, set it everywhere, and write it down beside the clock leader.

Latency, which is a setting

Dante devices buffer a little audio to survive network jitter, and that buffer is the latency setting: typically one millisecond or less on a simple system, more where the network is large or the path crosses many switches.

Set too low, subscriptions fail or audio glitches on a busy network. Set high, everything works and the system is slightly slower. Start at the default, raise it if the controller reports latency problems, and know that a latency error is a network message, not an audio one.

Clock symptoms, and what they actually mean

Look at the clock screen before the audio path.

How to do it

1. Decide which device should be the clock leader: central, permanent, reliable.
2. Mark it preferred in the controller, and mark a second as a backup.
3. Confirm every device reports as follower and locked.
4. Set every device to the same sample rate.
5. Leave latency at the default until something says otherwise.
6. Disable energy-saving features on every switch port in the path.
7. Watch the clock status for a few minutes under load.
8. Write down the leader, the rate and the latency with the system documentation.

What goes wrong

Practice it

On a small Dante system.

The Network Underneath

A Dante system is a network carrying time-sensitive traffic. Almost every serious Dante problem is a network problem, and almost every one of those is a switch that was never told what it was carrying.

What the network has to do

Carry audio without losing packets, deliver clock messages promptly, and not surprise anybody. That means gigabit links, switches with enough capacity for every port at once, and configuration that puts time-sensitive traffic first.

Small systems on a single switch with nothing else on it are forgiving. Large systems, shared networks and multi-switch paths are not, and the difference between them is configuration rather than luck.

Quality of service

QoS marks traffic with a priority so a switch knows what to send first. Dante marks its clock messages as the most urgent thing on the network and its audio just below, and a switch that respects those markings will deliver them ahead of a file copy.

A switch that ignores them treats a backup job as equal to the clock. That is why an unmanaged switch is fine on a dedicated audio network and dangerous on a shared one.

Multicast and IGMP snooping

Multicast is efficient when many devices want the same channels and catastrophic when the switch does not know who wants what. IGMP snooping lets the switch learn which ports have asked for which multicast streams and send them only there.

Snooping needs a querier somewhere on the network to keep asking. Snooping enabled with no querier is a well-known way to make a system that works for two minutes and then stops.

Separating audio from everything else

Best: a network that carries only Dante. Next best: a VLAN of its own on shared switches, with priority configured. Worst: sharing a general office network with printers, security cameras and a guest wireless system.

When you must share, talk to the IT department early, with numbers: how many devices, how much bandwidth, what priority, what ports. A clear request is usually granted; a vague one is usually refused.

Switch settings that break audio

• Energy-efficient ethernet, green ethernet or power saving: off, on every audio port.
• Flow control: off; it pauses traffic in a way audio cannot survive.
• Spanning tree: set so a topology change does not black out the audio for thirty seconds.
• Storm control and rate limiting: careful, or they throttle legitimate audio.
• Auto-negotiation forced to a fixed speed: usually unnecessary and often the cause of a fault.
• Unmanaged switches in a multicast system: no snooping, therefore flooding.

Cabling, fiber and distance

Copper runs to about a hundred metres including patch leads. Beyond that, fiber with the right optics, which also gives immunity to electrical noise and to the potential differences between two parts of a big building.

Use proper cable and proper terminations. A marginal patch lead that passes a laptop's file transfer will still drop packets under continuous audio, and it will do it intermittently, at night, in front of people.

Switch configuration for Dante

Nine decisions. Get these right and most problems never happen.

On the job

A conference system works all week in the rehearsal room and glitches in the ballroom. The venue's switch has green ethernet enabled by default; it puts ports to sleep between packets and the clock messages arrive late. One setting, changed in a minute, and three hours of investigation already spent.

What goes wrong

Practice it

On any managed switch you can log into.

Sizing a System

Before anything is bought or plugged in, somebody should work out how big the system actually is. It is arithmetic, it takes ten minutes, and it is the difference between a network that works at showtime and one that was fine until everybody turned up.

What a channel costs

A channel of audio on a network is a steady stream of samples. At 48 kHz and 24 bits, one channel is a little over a megabit a second of audio, and the packets it travels in add overhead on top — call it roughly one and a half to two megabits a second per channel once everything is counted.

That number is the one worth carrying. It means a gigabit link, which is a thousand megabits, does not carry a thousand channels — it carries a few hundred comfortably, and far fewer once you leave headroom, which you always should.

Flows, not channels

Audio does not travel as individual channels but in flows: bundles of channels sent together. A device has a limited number of flows it can transmit and receive, and that limit often bites long before bandwidth does.

This is why a small box may refuse a subscription from one more destination while most of its channels are still unused: not because the network is full, but because that device has run out of transmit flows. When a subscription fails on a system that is otherwise healthy, flow limits are the third thing to check, after sample rate and clock.

Finding the busiest link

Draw the system and count what crosses each cable. The busiest link is almost never the one you expect: it is usually the single cable into the console, the recorder, or the uplink between two switches, because those are where many devices' audio converges.

Work that number out at design time. A system that is comfortable everywhere except one uplink is a system that fails once, at the worst moment, in a way that looks like magic.

Latency, distance and when fiber starts

Copper runs to about a hundred metres including the patch leads at both ends, and beyond that the answer is fiber — which also gives immunity to electrical noise and to the voltage differences between distant parts of a large building.

Each switch a signal crosses adds a little delay, which is why the latency setting exists and why a system spread over several switches needs a larger one than a system on a single box. Count your switch hops when you set it.

Headroom and growth

Every system grows. Leave spare ports, spare channels and spare bandwidth, and say on the drawing that they are spare, so that the next person adds to the system rather than rebuilding it.

A useful habit: size for what the show needs, then check the answer against half again. If half again does not fit, the design is already at its limit on the day it is installed.

The arithmetic, in round numbers

Rough figures that are good enough to design with; check the exact ones against the platform's documentation.

How to do it

1. List every device and its transmit and receive channel counts.
2. Draw the network, including which devices share a switch.
3. Count the channels crossing every link, especially uplinks.
4. Multiply by roughly two megabits a channel and compare with the link.
5. Check each device's flow limits against how many destinations want it.
6. Add half again and see whether the design still fits.
7. Decide where fiber starts, and count switch hops for latency.
8. Write all of it on the drawing, including what is deliberately spare.

What goes wrong

Practice it

Size a system on paper: a band on stage, a console, an amplifier rack and a recording laptop.

Redundancy, Computers and Control

Three things separate a system that survives a bad night from one that does not: a second network that actually works, computers that behave themselves, and somebody in control of who may change what.

Primary and secondary networks

Dante devices with two network ports can be connected to two entirely separate networks. Audio flows on both, and if the primary fails the receiver simply keeps using the secondary. There is no switchover delay because nothing has to switch.

The catch is that it only works if the two networks are genuinely separate: different switches, different cable routes, different power where possible. Two cables through the same doorway into the same switch is not redundancy; it is two cables.

Computers on a Dante network

A virtual soundcard turns a laptop into a Dante device for recording, playback or processing. It is enormously useful and it is still a laptop: it sleeps, it updates, its network port powers down, and it has a firewall with opinions.

Configure it deliberately: sleep off, updates deferred, power saving off on the network adaptor, firewall permitting the traffic, and never the clock leader. Then test it for as long as the show will run.

Domain Manager and who may change things

Somebody has to decide who may re-route the system, and something has to enforce it. On a large or installed system that is Dante Domain Manager; on a smaller one it is device lock and a written note of who owns what. The next chapter covers both.

Firmware and versions

Devices run firmware and the controller runs software, and mismatches produce faults that look like everything else. Record the versions when a system works; the next chapter covers how and when to change them.

Documenting the system

Device names and what each one is, addresses, the clock leader and its backup, sample rate, latency, switch configuration, VLAN details, firmware versions, and the saved preset. That is the pack that lets somebody else keep it running.

It is also what you will want yourself when you return to the venue in eight months having forgotten all of it.

What makes a Dante system survivable

Each of these turns a show-stopping failure into an inconvenience.

How to do it

1. Confirm every redundant device has both ports connected.
2. Confirm the two networks share no switch, no cable route and ideally no power supply.
3. Play audio and unplug the primary link at a device.
4. Listen: there should be no interruption at all.
5. Check the controller reports the change.
6. Restore the primary and confirm it returns.
7. Repeat at the switch, not only at the device.
8. Write down what you tested, and when.

What goes wrong

Practice it

On any system with redundant devices, or one you can simulate.

Domains, Security and Who May Change Things

A Dante network with no governance is one where anybody with the controller and a laptop can re-route a building. On a touring rig that is fine, because the rig is yours. On a campus, a broadcast centre or a client's network it is not, and the answer is Dante Domain Manager.

What Domain Manager does

It puts devices into domains — logical groups that can be managed separately — and puts user accounts in front of them, so that changing a route requires being somebody rather than merely being present. It also logs what changed, when, and by whom.

That last part is the one people underestimate. A week after an incident, the question is always "what changed?", and a system that can answer it is a system that gets trusted.

Domains, sites and scale

Domains let one campus hold several independent systems on shared infrastructure: a theatre, a chapel and a lecture hall that must not be able to route into one another, all on the same network. They can also span subnets, which plain Dante does not, so a building with routed networks becomes manageable.

For a touring engineer this mostly matters at the other end: you arrive at a venue whose system is enrolled in a domain, and your laptop cannot see anything until somebody gives you an account or an unmanaged path.

Security on somebody else's network

Where Domain Manager is not used, the practical equivalents are device lock, which stops a device's configuration being changed without a passcode, and discipline: a written note of who owns the system and a rule that nobody re-routes what is not theirs.

Expect an IT department to ask about all of this. What is being added to their network, who can change it, what is logged, and how it is patched. Answering with domains, accounts and a logging story is the difference between being allowed on and being put on an island.

Firmware, versions and change control

In an installed system, firmware is change control rather than housekeeping: a version is chosen, tested and recorded, and it changes in a planned window rather than because an update was available.

Keep the versions with the documentation, update a system together rather than device by device, and never update anything during a show week. A rig with three firmware generations in it is a rig with intermittent faults and no pattern.

Handing a system over

The client inherits the network: device names and addresses, the domain structure and its accounts, the clock leader, sample rate and latency, the switch configuration, the firmware versions, the saved preset and a plain account of how to restore it.

Train somebody, and leave the one-page version they will actually use: how to check the system is healthy, what the three commonest faults look like, and who to call.

Governing a Dante network

How much of this you need is set by whose network it is.

On the job

A university has three venues on one network. Without domains, a visiting engineer in the theatre can see and re-route the chapel's microphones. With them, they see the theatre, are logged doing it, and the chapel is somebody else's problem entirely.

What goes wrong

Practice it

Take an installed system you can ask about.

When It Goes Wrong

Three faults account for nearly everything: a device that will not appear, a subscription that will not complete, and audio that drops out. Each has a short list of causes and a fixed order to work through, and the order is what makes you fast.

A device will not appear in the controller

Work outward from the device. Is it powered? Is its network light on? Is it on the same physical network as your computer? Is your computer's network adaptor the right one — a laptop with wifi and ethernet will often look at the wrong one?

Then addressing: on a simple network, devices give themselves addresses and find each other; if one is set to a fixed address in a different range, it is invisible to everybody. Finally the switch: wrong VLAN, blocked port, or a dead patch lead.

A subscription will not complete

Short list, in order: sample rates differ; the transmitting device has run out of flows; the latency setting is too small for this network; the transmitter is no longer there; or the network will not carry the multicast.

The controller usually says which of those it is, in a form that does not look like an answer at first glance. Read the message, then check the clock, then check the rate, then the latency.

Dropouts, clicks and glitches

This is the clock until proved otherwise. Look at clock status first, then at whether the fault affects every device or one, then at the switch settings — energy saving, priority, snooping — and only then at cables.

If one device alone is glitching, it is that device's link or that device. If everything is glitching together, it is the clock or the network. That single distinction halves the problem in one question.

Faults that are not Dante at all

• A muted channel on a console with a perfect green tick above it.
• Gain structure at the analogue edge, not the network.
• A patch on the receiving device that sends the channel nowhere.
• Two devices with the same name after a preset was applied twice.
• Somebody else's system on the same network, doing something surprising.

Working calmly in front of people

Cover first: get the show something usable, even if it is a spare channel or an analogue line, and then diagnose. Say what you are doing out loud to whoever needs to know, and give an honest estimate.

Change one thing at a time and put back anything that was not the fault. The temptation under pressure is to change five settings at once, and it turns a ten-minute fault into an evening.

Where to start with each fault

Each has a fixed order. The order is what makes you quick.

How to do it

1. Cover the show with a spare path first, then diagnose.
2. A device will not appear: check it has power and a link light, and that your computer is on the same network, on the right adaptor.
3. Then the switch: is the port up, and on the right VLAN? Swap the patch lead and move the device to a known-good port.
4. If it appears elsewhere, the fault is the port or the lead. If it appears nowhere, check its addressing and reset it if you must.
5. A subscription will not complete: read the controller's message, then check sample rate, clock, latency and flow limits, in that order.
6. Dropouts: look at clock status first, then decide whether every device is affected or only one.
7. Every device: the clock or the switch settings (energy saving, priority, snooping). One device: that device's cable, port and firmware.
8. Change one thing at a time, put back what was not the fault, and write down what it turned out to be.

What goes wrong

Practice it

Break a working system deliberately, four times.

Putting Dante to Work

Everything so far comes together on a real job: a stage box, a console, an amplifier rack, a recorder and a laptop, on a network that has to survive a day of people walking past it.

Combine audio and networking skill into reliable networked audio.

Dante in a real system

In practice, Dante is part of a larger audio system: a console, processors, stage boxes, amplifiers, and more, connected over a Dante network instead of (or alongside) traditional cabling, with all the audio routed in software. This is the live-sound and installed-audio world from Audio Basics and Live Sound, now networked — the same signal flow and mixing, with Dante carrying the audio between devices flexibly. Understanding how Dante fits into a real audio system (it is the networked interconnect between your audio gear) shows why it is so useful: it makes large, complex audio systems far more flexible and manageable.

Working with Dante in a real system means setting up the network and devices, routing the audio for the show or installation, and keeping it running reliably — combining the audio craft (knowing what audio needs to go where) with the networking craft (a sound, well-configured network). The Dante-competent professional bridges these, which is exactly the combined skill set modern audio increasingly demands. Dante is the connective tissue of networked audio systems.

A typical live rig: stage boxes taking microphones, a console mixing, a processor and amplifiers driving the PA, a recorder taking a split of everything, and a laptop for playback or virtual soundcheck. One switch, or two if it is redundant, and one clock.

A typical installed system: microphones and processors in ceilings and racks across a building, amplifiers in plant rooms, control systems calling presets, and a network shared with the building's IT under a VLAN.

Reliability and good practice

Because Dante carries show-critical audio over a network, reliability matters, and good practice ensures it: use a properly configured network (good switches, and for larger systems the segmentation and QoS that timing-sensitive audio needs), keep clocking healthy, name and document the system clearly, and test the routing and audio before the show — the same prep-and-test discipline every AV job asks of you, applied to networked audio. A well-set-up Dante system is reliable and flexible; a poorly-configured one can have dropouts or sync issues, so doing it right matters.

Reliability also draws on the AV-over-IP design thinking: for critical or large Dante systems, the network is designed deliberately (not just plugged together), and redundancy can be used for mission-critical audio. The professional treats the Dante network as part of the audio system to be engineered and tested, not an afterthought. Combining sound networking practice with audio craft is what makes Dante deliver reliable, professional networked audio.

The habits are boring and they are the whole job: name everything, keep the network for audio, set the clock deliberately, save presets, record firmware versions, and test the redundancy you claim to have.

Then watch it. The controller shows clock health, latency and errors in real time, and a system with warnings is a system telling you what will fail tonight.

Where analogue meets the network

Every Dante system begins and ends in the analogue world. A microphone still needs gain set properly at the stage box; an amplifier still needs a sensible level arriving; and the converters at each end still decide what the audio sounds like.

Gain structure has not gone anywhere. What has changed is that a badly set input is now badly set at every destination subscribed to it, including the recording and the broadcast feed.

AES67 and other systems

AES67 is a standard for carrying audio over IP that different systems can share. Dante devices can run in an AES67 mode, which lets them exchange streams with equipment from other ecosystems.

It is interoperability, not equivalence: some Dante features do not travel, the setup is more manual, and clocking across the boundary needs care. Where a job needs it, plan it, test it well before the day, and document exactly what was agreed with the other system's owner.

Tour against install

A touring rig is rebuilt every day: presets matter enormously, the network is yours, and speed is everything. An installed system is built once and lives for years: documentation matters enormously, the network is somebody else's, and the person maintaining it has never met you.

The technology is identical; the habits are not. A touring engineer who installs a system, or an integrator who tours one, should know which set of habits they have brought with them.

Working with the IT department

On installed and corporate work the network belongs to somebody else, and they will ask what you are putting on it. Answer with numbers: how many devices, what bandwidth, what traffic markings, whether multicast, what ports, whether you need a VLAN of your own.

Bring a one-page requirements note to that meeting. Nothing opens a door faster than being the audio person who already knows what they are asking for.

A working Dante rig, and who owns what

Most jobs are a version of this list.

How to do it

1. Plan the channel count, the devices and the switch capacity before the day.
2. Build on a dedicated switch, or a VLAN if the network is shared.
3. Power up, confirm every device appears, and name everything.
4. Set sample rate, clock leader and preferred backup.
5. Apply the saved preset if you have one, and check it against reality.
6. Route what is missing, and check every tick.
7. Test redundancy by unplugging the primary during soundcheck.
8. Save a preset, note the versions, and watch the clock through the show.

What goes wrong

Practice it

Design a Dante system for a small live show on paper.

Talking to Systems That Are Not Dante

Not everything on a modern job is Dante. Broadcast plants, other manufacturers' ecosystems and an increasing amount of installed infrastructure speak a different dialect of the same idea, and somebody has to make the two ends agree.

What AES67 actually is

AES67 is a standard that says: if two audio-over-IP systems both do these particular things — this clocking, this packet format, this way of describing a stream — they can exchange audio. It is an interoperability agreement rather than an ecosystem of its own.

Dante devices can run in an AES67 mode, and then a stream from a Dante device can be received by something that is not Dante at all. What travels is audio; what does not travel is most of the convenience — automatic discovery, the routing grid, device names and the rest of what makes Dante pleasant.

What it costs you

Setup is more manual: streams are described and configured rather than clicked together, sample rates and packet times must match on both sides, and multicast is usually involved, which means the switch configuration from the network chapter becomes mandatory rather than advisable.

Clocking across the boundary needs care too: both systems must follow the same PTP reference, and the two ecosystems may prefer different profiles of it. This is a conversation to have weeks early, with the other system's owner, not a setting to discover on the day.

ST 2110 and the broadcast plant

Broadcast has its own family of standards for carrying video, audio and data over IP, and the audio part of it is closely related to AES67. A modern broadcast facility routes everything as streams, timed by PTP, with an orchestration system deciding what goes where.

For an audio person arriving at that boundary, three things matter: the plant's PTP is the master and your system follows it; streams are described and registered rather than discovered; and the broadcast engineers have conventions about naming and numbering that are worth adopting rather than arguing with.

Making an interop actually work

Test it early, with the real equipment at both ends, and document what was agreed: sample rate, packet time, multicast addresses, clock source and profile, and who owns each half. Interoperability that was assumed is the commonest way a large job loses a day.

And keep a plain-language note of what the boundary can and cannot do, because somebody will ask for a channel to be re-routed across it five minutes before a rehearsal, and the honest answer is usually "not quickly".

Dante, AES67 and ST 2110 side by side

Same idea, different promises.

How to do it

1. Name the owner of each side, in writing.
2. Agree the clock: one PTP reference, and which profile.
3. Agree sample rate and packet time on both sides.
4. Agree how streams are described and addressed, including multicast.
5. Configure the switches for multicast properly before testing.
6. Test with the real equipment at both ends, weeks early.
7. Document every setting that worked, and who agreed it.
8. Write the plain note: what the boundary can and cannot do quickly.

What goes wrong

Practice it

For any interop you can find or imagine.

Certification Levels, Troubleshooting & Path

The certification levels exist because employers wanted a way of asking "can this person be trusted with the network?". They are a reasonable map of the subject, and the competence matters more than the certificate.

Dante is certified in levels — and using it well means setting up and fixing it.

The certification levels and troubleshooting

Dante certification is offered in levels of increasing depth: Level 1 covers Dante basics and getting a simple system running; Level 2 goes deeper into networking and larger, more complex Dante systems; Level 3 is advanced/expert, hands-on, for serious Dante system design and management. The levels let you build and certify your Dante competence progressively, and the credential is recognised as proof of networked-audio skill. The official certification (from Audinate) provides the authoritative content for each level; this book orients you to what they cover and prepares you to pursue them.

Using Dante well includes troubleshooting, which follows the systematic method applied to a networked-audio system. Common Dante issues trace to: the network (a device not on the network, a bad cable or switch problem — the networking checks from Networking Basics), clocking (sync problems if the clock is disrupted), naming/routing (audio routed wrong, or a device hard to find because of unclear names), and the usual audio checks. Because Dante is audio over a network, you troubleshoot it with both audio and networking thinking — is the device on the network, is clocking healthy, is the routing correct, is the audio itself fine? This combined diagnosis is a key Dante skill.

Broadly: the first level is what Dante is, how to route it, and how to set up a small system. The second adds real network configuration — switches, quality of service, redundancy — and the diagnostics that go with them. The third is design and large-system work, including domains, interoperability and systems somebody else will maintain.

Read them as a syllabus rather than as a ladder. Almost everybody works at the first two levels daily and reaches for the third when a system grows beyond one switch and one room.

The path and why Dante matters

The path through Dante certification is to learn and certify level by level — starting with Level 1 fundamentals, progressing as your experience and the demands of your work grow. For an audio professional, Dante competence is increasingly essential because networked audio is now standard in pro audio, and the certification is a recognised, valuable credential. This book prepares you with the understanding of what Dante is and how it works; the official certification levels build and verify it formally. Pursue the levels through Audinate's official program, grounded in real hands-on Dante experience.

Dante matters because it represents where pro audio has gone: audio is now routinely networked, and the ability to set up, route, and troubleshoot Dante systems is a core modern audio skill. It connects your audio knowledge and your networking knowledge into a powerful, in-demand capability. Whether you formally certify or simply become competent with Dante, understanding networked audio is essential for working in professional audio today — and this book gives you that foundation, with the certification path to take it further.

Networked audio is now the default on new systems, which means this competence is becoming part of being an audio technician rather than a specialism. The people who learned it early are the ones being asked to design systems now.

It also opens doors sideways: into system technician work, into installed systems and integration, into broadcast, and into the wider world of audio-over-IP where the vocabulary transfers almost entirely.

What each level actually tests

Level 1 is whether you can make it work: what Dante is, what a subscription is, how to name devices and channels, how to route in the controller, how to set a sample rate and a clock leader, and how to build a small system on one switch. Somebody who has built the two-device rig in this book and proved it has done most of it.

Level 2 is whether you can make it reliable and diagnose it: switch configuration and why each setting matters, unicast against multicast and the snooping that goes with it, redundancy built and tested, clocking in depth, latency as a deliberate setting, and the discipline of reading the controller's own status screens before touching anything.

Level 3 is whether you can design something other people will maintain: large systems across switches and sites, domains and user access, interoperability with systems that are not Dante, documentation somebody else can work from, and the judgement to size a system before it is bought.

Preparing for them honestly

The examinations are online, they are not long, and they test recall as much as judgement. That makes them easy to pass with revision and easy to pass without competence, which is worth being honest about: the certificate is evidence that you studied, and the competence is what happens when a device will not appear at five to eight.

So prepare by building. Put two devices on a switch and break them four ways. Change a sample rate and watch subscriptions fail. Set a laptop as clock leader and close its lid. Pull the primary cable of a redundant pair while audio plays. Each of those teaches a question the examination asks, and none of them can be forgotten in the way a memorised fact can.

What each level is really testing

Level one: can you make it work. Level two: can you make it reliable, and can you find out why it is not. Level three: can you design something that keeps working when you are not there.

Those three questions are the whole trade in miniature, and they apply well beyond Dante.

Keeping the skill current

• Build a two-device system at home and break it deliberately.
• Read the controller's status screens on every system you touch.
• Ask to see the switch configuration wherever you work.
• Keep your own template documentation pack.
• Learn what AES67 does and does not guarantee.
• Follow firmware release notes for the devices you use most.

Being the person who knows

On most jobs there is one person who understands the network part, and everybody else is relieved that somebody does. That position is worth having, and it is earned by being calm, methodical and willing to write things down.

It also carries a duty: explain rather than mystify. A crew that understands why the clock leader matters will not unplug it, and that is worth more than any amount of expertise held privately.

The levels, as a syllabus

Read them as three questions rather than three certificates.

Practice it

Test yourself honestly against the three questions.

Putting It Together

One last pass through the whole thing, in the order you would actually do it: work out how big the system is, build it, prove it, write it down, and know what you would do on the night something breaks.

Dante is modern audio's network — learn it, certify it, and use it well.

The whole picture

Stepping back, Dante is the way professional audio is increasingly carried and routed — many channels over a standard network, patched in software, interoperable across manufacturers, synchronised by shared clocking, and managed through the controller. Working with it combines your audio knowledge (the signals and what they need) and your networking knowledge (switches, addressing, segmentation, QoS) into the ability to set up, route, troubleshoot, and run networked audio systems. That combined capability is exactly what modern pro audio needs, and the Dante certification levels recognise and build it. Seeing how audio and networking unite in Dante is the goal of this book.

This places Dante at the meeting point of two disciplines — audio and networking — and, as a credential, alongside the other certifications. The professional who masters networked audio is equipped for where the field is, and Dante is the dominant technology to know. Understanding it as networked audio, routed in software, on a well-designed network, with healthy clocking, is the framework this book provides.

Audio as data, on a network, routed in software, timed by one clock. Every chapter of this book is one of those four words examined: the audio at the analogue edges, the data across switches, the routing in the controller, and the clock that everything follows.

When something is wrong, ask which of the four it belongs to. Glitches are usually the clock. Missing devices are usually the network. Silence with a green tick is usually the audio. Wrong channel is usually the routing.

Your path forward

Your path with Dante: build hands-on experience setting up and routing Dante systems, pursue the certification levels through Audinate's official program (starting at Level 1 and progressing), and deepen both your audio and networking skills since Dante draws on both. This book has oriented you — what Dante is, how it works, the certification levels, and the skills they cover — so you can pursue it knowledgeably. The detailed, authoritative training and exams come from the official Dante certification program.

Whether you formally certify or simply become Dante-competent, networked audio is now an essential professional capability, and Dante is the technology to know. Master it by combining your audio and networking foundations, getting hands-on with real Dante systems, and pursuing the certification levels — and you will be equipped for modern professional audio, where the sound increasingly travels on the network. Dante is the present and future of audio interconnection, and competence in it is a genuine career asset.

Build a small system of your own and live with it. Break it deliberately and fix it. Read the controller's status screens on every job you touch, even when nothing is wrong, so that you know what healthy looks like.

Then ask, on every site, to see the switch configuration. It is the single biggest gap between people who use Dante and people who understand it, and it is the part that decides whether a show survives a busy network.

Practical sign-off

Dante skill is built hands-on. The learner connects Dante devices, routes audio in the controller, confirms clocking, troubleshoots an issue, and understands the certification levels. Official certification is earned through Audinate. A mentor signs off when the learner can set up and route a small Dante system.

• Connected Dante devices onto a network correctly
• Routed audio channels in the controller software
• Confirmed healthy clocking and clear device naming
• Troubleshot a Dante issue using audio + networking thinking

How big is this system?

Before buying or building, count: channels in and out of every device, total channels crossing each network link, and how many devices want the same channels. Those three numbers decide the switch, the flows and whether multicast is worth the configuration.

A useful habit is to work out the busiest link in the system — usually the one into the console or the recorder — and check it against what a gigabit port can carry. Systems get into trouble at the link level long before the network as a whole is full.

A build, in order

Switch first, configured. Devices on, and every one appearing in the controller. Names and labels. Sample rate. Clock leader and backup. Preset applied or routing built. Ticks checked. Redundancy tested. Preset saved. Documentation written.

Doing it in that order means each step is proved before the next depends on it, which is why an experienced person builds a forty-device system faster than a beginner builds four.

The documentation pack

Device names and what each one is, addresses, the clock leader and its backup, sample rate, latency, switch configuration, VLAN details, firmware versions, the channel list, and the saved preset. One page plus the preset file.

Hand it over, keep a copy, and update it when anything changes. In an install it is the difference between a system that is maintained and one that is replaced.

What to carry into every job

• A laptop with the controller installed and its network settings already right.
• A known-good patch lead, and a second one.
• Your own small switch, configured, for when a venue's is a mystery.
• The documentation pack for any system you have built before.
• A written note of the clock leader, sample rate and latency you expect.
• The habit of looking at clock status before anything else.

The four words, and what fails in each

Ask which of the four a symptom belongs to before you touch anything.

How to do it

1. Count the channels and find the busiest network link.
2. Configure the switch before anything is plugged into it.
3. Power up and confirm every device appears in the controller.
4. Name every device and label channels.
5. Set one sample rate everywhere.
6. Set the preferred clock leader and a backup, and confirm every device locks.
7. Apply the preset, or build the routing in device order.
8. Check every subscription has a tick, and listen to several.
9. Test redundancy by unplugging the primary during soundcheck.
10. Save the preset, write the documentation pack, and watch the clock through the show.

What goes wrong

Practice it

Build, break and document a system of your own.

Glossary

What the gear actually looks like

Every device named in this book, in one place. Recognition is the whole point of Chapter 4 — use this page to attach a picture to each name before you meet it on a dock at six in the morning.

Audio

Dynamic microphone

Condenser microphone

Wireless handheld

Radio rack

Mixing console

Stage box / snake

Power amplifier

Main loudspeaker

Subwoofer

Stage monitor wedge

In-ear monitors

DI box

Video

Camera

Video switcher

Scaler / processor

Projector

LED wall panel

Confidence monitor

Lighting & control

Conventional fixture

Moving-head fixture

Lighting console

Dimmer

Show controller

Media server

Networking & infrastructure

Network switch

Patch bay

Equipment rack

Power distribution

Cable tester

A properly coiled cable

Connectors, close up

XLR

TRS / TS ¼-inch

SDI on BNC

HDMI

Cat5e / Cat6 (RJ45)

Fiber optic

DMX (5-pin XLR)

AC power — not signal