Digital Audio Network Tech Rider: Routing, Clock, and Redundancy

TL;DR — A digital audio network rider should name every device, port, transmitter, receiver, channel route, sample rate, clock leader, switch, cable path, control computer, and responsible technician. If redundancy is required, draw two genuinely separate supported paths and define failover testing. Matching connectors, protocol labels, or visible device names do not prove format, routing, firmware, or network compatibility.

Table of contents

1. Define the network boundary
2. Inventory devices and physical paths
3. Build the channel-routing matrix
4. Assign clock, addressing, and control
5. Design supported redundancy
6. Advance and test the network
7. FAQ

Define the network boundary

“Network audio” does not describe one interchangeable system. Begin with:

• protocol and required operating mode;
• touring and venue devices that exchange audio;
• FOH, monitor, stage-rack, wireless, recording, broadcast, playback, and processor endpoints;
• number and direction of channels;
• sample rate and other shared format settings;
• primary-only or supported redundant operation;
• providers and operators for switches, cables, adapters, and control computers.

Keep control traffic, audio transport, internet, lighting, intercom, and other services distinct in the rider even when an approved design shares infrastructure. A qualified system owner should approve the topology against the actual protocol, hardware, firmware, switch configuration, and venue policy.

If the goal is to share microphone inputs between consoles, also read the microphone splitter tech rider. A network diagram supplements the show input list; it does not replace source names, physical positions, or responsibilities.

Inventory devices and physical paths

Create a device table before drawing routes.

This is an example structure, not a compatibility promise. Add exact manufacturer, model, interface card, firmware, and software details when they affect interoperability.

On the topology drawing, show every endpoint, port, switch, cable path, connector, optical module, media converter, control computer, location, and tour-to-venue demarcation. Note routes that affect cable protection, access, or changeover time.

Never connect unfamiliar networks during load-in because a port appears available. The system owner must confirm its function, mode, addressing behavior, and topology first.

Build the channel-routing matrix

Use stable device and channel names that map back to the show paperwork.

Replace the example with actual identifiers. Keep routes aligned with the input list and patch sheet, monitor destination list, console files, recording tracks, and system-processor destinations.

Document subscription, multicast, unicast, flow, or bundle details only when the system exposes them and the operator needs them. Save a known-good routing file when supported, but keep a readable matrix in the Rider for review and recovery.

Assign clock, addressing, and control

Clock plan

Networked digital audio devices must agree on timing and format. Identify:

• the intended clock leader or master;
• any preferred-leader setting;
• external synchronization, if used;
• sample rate and protocol mode;
• devices that cross clock domains;
• who may change clock settings;
• status indicators the operator will verify.

If the system elects a leader automatically, document the intended result and verify the actual leader after every device is connected.

Addressing and names

State whether addressing is automatic, static, or venue-managed. Record subnets, VLANs, gateways, or DHCP services only when they belong to the approved design. Never publish passwords or sensitive credentials in the rider.

Device names should be unique, stable, and descriptive, such as TOUR-FOH, TOUR-MON, and VENUE-SR-RACK. Channel names should match the show list wherever possible.

Control ownership

Name the control application, compatible version, computer, connection, and operator. Define who may rename devices, change routes, update firmware, alter switches, or connect equipment.

Firmware updates are maintenance work, not an automatic load-in step. Confirm and test versions before show day; do not casually update a known-good production system.

Design supported redundancy

Redundancy exists only when the protocol and relevant devices support the design. State which failure it should tolerate.

Where a system defines primary and secondary networks, keep them separated exactly as its manufacturer requires. Do not bridge redundant paths unless the approved design explicitly calls for it. A second cable through the same unsupported endpoint, switch, power source, or physical route may not provide useful protection.

Document power for switches and critical endpoints. Network-path redundancy cannot protect against every shared device or power failure.

Advance and test the network

Before show day

1. Exchange device, card, firmware, software, protocol, and mode details.
2. Close input, output, monitor, recording, and system channel counts.
3. Approve topology, switches, addressing, sample rate, and clock.
4. Build a readable transmit-to-receive routing matrix.
5. Assign cable, control, routing, firmware, and troubleshooting owners.
6. Agree on redundancy requirements and a safe test method.
7. Preserve a known-good configuration and readable fallback patch.

On site

1. Place and label endpoints, switches, ports, and cable paths.
2. Connect only the approved topology.
3. Verify discovery, names, addresses, firmware, and format.
4. Confirm the actual clock leader and synchronization status.
5. Apply and inspect every required route.
6. Pass and listen to audio through every source and destination.
7. Test control access without exposing credentials.
8. Perform the agreed primary or secondary path failure test.
9. Save the final route state and note deviations in the Rider.

The system technician, FOH engineer, monitor engineer, and recording engineer can be invited to edit and save the same Rider and inspect its history. Export a dated PDF after the final topology and routes are confirmed.

Common audio-network mistakes

Writing only the protocol name. Add devices, ports, firmware, modes, format, clock, routes, switches, and owners.

Treating discovery as proof of audio. A visible device can still have the wrong route, sample rate, clock, or channel assignment.

Using factory device names. Stable names make routing and fault reports understandable.

Letting routes drift from the input list. Use the same source and destination names.

Calling any second cable redundant. Verify end-to-end support, separated paths, power, and failover behavior.

Pre-show checklist

• Protocol, mode, device, card, firmware, and software details match.
• Every endpoint, port, switch, cable path, location, and provider is listed.
• Routes match the show input and output lists.
• Sample rate, clock leader, and synchronization path are confirmed.
• Addressing, names, control access, and change authority are assigned.
• Primary and secondary networks follow the approved design.
• Single points of failure and fallback patches are visible.
• Every route has been heard, not merely discovered.
• The failover test passes and the final route state is saved.

FAQ

What should a digital audio network tech rider include?

Include the exact protocol and mode, devices, interface cards, firmware, ports, switches, cable paths, channel routes, sample rate, clock leader, addressing, control application, providers, redundancy, fallback, and test procedure.

How do you document Dante routing for a show?

List every transmitting device and channel beside every receiver, using names that match the show lists. Also document ports, sample rate, clock outcome, network paths, control ownership, and a saved known-good route state.

Does a Dante network need a separate switch?

It depends on endpoint count, topology, connection mode, bandwidth, redundancy, and the approved venue design. Use compatible, correctly configured infrastructure and verify Audinate and device-manufacturer requirements instead of assuming any available network is suitable.

What is the clock leader on an audio network?

The clock leader is the device or timing source that other digital-audio devices follow. Identify the intended leader, sample rate, external synchronization, controller, and method for verifying the actual clock state.

How do you test redundant audio networks?

Confirm that every relevant device supports the documented redundant mode. Pass audio through all routes, safely disconnect one approved path, verify expected audio and status reporting, restore it, and repeat for the other path when the system procedure permits.

Keep the topology and show patch in one Rider

Build the stage plot and input list in Techrider.live, invite the system and console engineers to edit the same Rider, and export one confirmed PDF after routing and failover tests pass.

---

Last updated: 2026-08-10 · Reviewed for digital-audio topology, routing, clock, control, redundancy, and show-advance planning.