Dante

The Dante page is a visual routing matrix for managing Audinate Dante audio-network subscriptions. From one screen you discover the Dante devices on the network, then create and clear audio routes between transmitter (TX) and receiver (RX) channels — the same crosspoints you would otherwise patch in Dante Controller. Subscription changes made anywhere on the network are reflected back on the matrix in near real time.

Open Dante

Licensing

Dante is a premium integration. Adding a dante device — and opening this page — requires the Dante product in your license. Existing devices keep running if a license later changes. See License.

How it works

GEM does not speak the Dante protocol directly. It drives a bundled command-line tool (netaudio) that discovers devices and edits subscriptions over the Dante/mDNS multicast network. GEM ships and auto-updates this tool as part of its Python environment — you do not install or configure anything beyond the device record. If that environment was never provisioned, discovery cannot run; see Troubleshooting.

Because GEM rides on the same network plumbing as Dante Controller, you can use both at once — a route you patch in Dante Controller shows up on this matrix, and vice versa.

Routing is applied directly to the device, not via a network scan. Discovering devices needs an mDNS browse (a few seconds), but changing a route only needs the receiver's address — which GEM already knows from discovery — so route add/clear and source reads are sent straight to the device and complete in well under a second. This is what keeps switching a source from feeling like something hung. Reading the full route list for the matrix works the same way: one batched direct read fans out across every discovered receiver. If a device isn't yet known (or the direct engine is unavailable), GEM automatically falls back to the browse-based path — for route reads, per receiver, so one unreachable device doesn't blank the rest of the matrix.

netaudio browse invocations are serialized — one process at a time — because concurrent mDNS browses contend on the multicast socket and slow each other down. User-initiated actions take priority over background discovery and polling, so anything queued behind a scan waits only for the scan already in progress, not the whole background backlog. Browse-based actions that target a device already on the matrix also use a shorter discovery window, since the device is known to be present. (Direct route changes don't queue at all — they don't use mDNS.)

Prerequisites

• GEM server on the same Layer-2 network as the Dante devices. Dante discovery and routing use multicast, which must reach the GEM host. If GEM is on a different VLAN, multicast (mDNS) must be routed to it. The Dante conmon groups matter too: when a device's routing changes it multicasts an unsolicited change nudge on 224.0.0.231:8702 (no registration required — the same mechanism Dante Controller uses for its instant view), and every device heartbeats once a second on 224.0.0.233:8708. These groups are link-local scope and are normally not routed between VLANs — with L2 adjacency GEM sees route changes at wire speed; without it, GEM falls back to fast polling automatically. GEM joins the groups on every network interface, so a multi-homed host (Dante on one NIC, internet on another) works as long as one NIC has adjacency; the journal reports whether the heartbeat stream is being received.
• A provisioned GEM Python environment. The bundled netaudio tool lives there. A normal GEM install provisions it automatically; if it is missing, re-run the GEM installer and choose the Python/dependencies step. Without it, a Dante device will fail to connect and no devices will be discovered.
• One dante device record. Create a single device in System → Devices with the driver set to dante and Enabled set to Yes. No IP address, port, or attributes are required — the driver finds Dante devices itself. Only one Dante device is needed per site; this page uses the first enabled one.

Optional device attributes

Attribute	When to set it
interface	On a multi-homed GEM host, set this to the NIC on the Dante VLAN (for example eth1). Discovery is then attempted only on that interface instead of every NIC (VPN/overlay interfaces included), which is strongly recommended — it typically cuts a full discovery from ~20s to under 10s and avoids spurious mDNS socket errors.
discovery_timeout	The mDNS browse window in seconds (default 5). Raise it if slow devices are missed; note netaudio browses for this long and then queries each device it found, so higher values make every operation slower.
force_unicast	Disables multicast-flow creation for every zone on this controller, so set_zone_source routes as per-receiver unicast subscriptions. Off by default (multicast). The same attribute can be set on an individual zone to opt just that receiver out — see Multicast flows.

Page layout

The Dante Discovery toolbar sits at the top of the page and stays visible at all times, so you can start, stop or refresh a scan without losing your place. Below it, the page is split into two tabs:

Tab	Contents
Discovery	Discovered Devices — the inventory of everything mDNS has found, with addresses, channel counts, route counts and zone bindings.
Routing	The Routing Matrix — the crosspoint grid where you create and clear subscriptions.

Each tab scrolls independently, and both keep their state when you switch — collapsed devices on the matrix stay collapsed while you check an address on the Discovery tab.

Discovery

The Dante Discovery toolbar controls scanning.

Control	What it does
Start Discovery	Begins scanning for Dante devices and starts watching for subscription changes. Newly powered-on devices appear within about thirty seconds. The status badge changes to Discovering….
Stop Discovery	Stops scanning and watching for changes. Already-discovered devices stay on screen. The button toggles back to Start Discovery and the badge reads Idle.
Refresh	Re-reads the current device list and all active routes from the driver. Use this after changing devices in Dante Controller, or to redraw the matrix.

Start Discovery and Stop Discovery are the same button toggling state — only one is shown at a time. To the right, Controller: names the Dante device every action on this page runs through — click it to inspect its address, driver and online state in place, without leaving the discovery run or the matrix. Then a badge shows Discovering… or Idle, followed by a count of how many Dante devices have been found.

Interface: names the NIC discovery is pinned to, read from the Dante device's interface attribute. If it reads all NICs, no interface is set and netaudio browses every one of them — VPN and overlay interfaces included. On a multi-homed host that is several times slower and is the most common cause of a discovery that is slow, incomplete, or empty; setting the attribute to the NIC on the Dante VLAN typically cuts a full discovery from ~20s to under 10s. On a single-NIC host, all NICs is fine and needs no action. The value is read when the page loads, so set the attribute and reload the page to see it change.

note

Discovery starts on its own as soon as the Dante device connects, so the matrix often populates before you click anything. The Start/Stop buttons let you pause and resume it from this page.

Discovered Devices

The Discovery tab lists every device found so far, sorted by name. Discovery reports more than the device name, and this is where the rest of it is visible:

Column	What it shows
Name	The Dante device name — the same name used as the row and column headers on the matrix, and as a zone's address when a receiver is synced to a zone.
IP Address	The device's IPv4 address on the Dante network, as advertised over mDNS. Use it to reach a device's own web interface, or to confirm a device landed on the VLAN you expected.
MAC	The device's hardware address — useful for matching a device against a switch's MAC table or a DHCP reservation.
Model	The model the device advertises, where it publishes one.
TX / RX	How many transmitter and receiver channels the device has. A device with 0 in a column does not appear on that axis of the matrix.
Sample Rate	The device's current sample rate. Highlighted in amber when it differs from the rest of the network — see Sample-rate mismatch.
Routes	How much of the device is actually patched. 3 / 8 in means three of its eight receiver channels have a source; 5 out means five subscriptions elsewhere on the network take their audio from this device. An amber ⚠ badge counts routes on this receiver that are not passing audio — the same fault and stale states the matrix colours red and amber.
Zone	The GEM zone backed by this device, if one exists — click it to inspect the zone without leaving the page. not synced means the receiver has no zone yet; run the sync_zones command on the Dante device to create one. Receivers only: transmitters show a dash, since zones model outputs.

A dash means the device did not advertise that field. Before anything has been found, the tab says so — whether a scan is currently running, or whether you still need to click Start Discovery.

The same details appear in the tooltip on each device's header cell on the matrix, so you can check an address while patching without switching tabs. Hover a TX column header or an RX row header to see it.

note

This table reflects what mDNS discovery reports, which is not necessarily what GEM is configured with. The address a zone uses is stored on the zone as its ip_address attribute, refreshed from discovery each scan.

Sample-rate mismatch

Dante will not subscribe a receiver to a transmitter running at a different sample rate. The route is accepted, and then simply never passes audio — which makes a mismatch one of the harder faults to spot from the matrix alone, since the crosspoint can look perfectly healthy.

When the discovered devices are not all at the same rate, a warning appears above the table naming every rate in play, and each device that differs from the rate the majority runs at is highlighted in its Sample Rate cell. Fix it in Dante Controller by setting every device to a common rate; GEM only reports what the devices advertise.

Routing Matrix

The Routing tab is the main interface for creating and clearing audio routes. The grid needs both a transmitter and a receiver to draw; until it has them the tab says which half is missing and how many of each have been discovered, rather than showing an empty panel.

Layout

• Columns (across the top): TX (transmitter) devices and their individual output channels. The top-left corner cell shows the orientation: TX ► across, RX ▼ down.
• Rows (down the left): RX (receiver) devices and their individual input channels. A receiver backed by a GEM zone carries a link icon on its header — click it to open that zone in place, without leaving the matrix. The matrix speaks Dante device names; everything else in GEM speaks zone names, so this is what connects a row of the grid to the thing a macro, widget or trigger addresses.
• Channel crosspoints: the cell where a TX channel column meets an RX channel row — one subscription.
• Device intersections: the cell where a TX device column meets an RX device row — whole-device 1:1 routing. See Device-to-device routing.

A legend above the grid names every cell colour.

Cell states

State	Appearance	Meaning
No route	Empty cell	No subscription between these channels.
Active	Green cell with a checkmark (✓)	The RX channel is subscribed to the TX channel and the transmitter is on the network.
Transmitter not discovered	Amber cell with a question mark (?)	The subscription exists on the receiver, but the transmitter it names is not currently discovered — the route cannot be passing audio.
Not connected	Red cell with an exclamation mark (!)	The receiver itself reports the subscription as not connected (wrong sample rate, clock domain mismatch, unresolved name, bandwidth).
Device routed 1:1	Dark blue device-intersection cell with a checkmark (✓)	Every channel of a 1:1 device route is subscribed.
Device partially routed	Light blue device-intersection cell with a half circle (◐)	Some — but not all — of the receiver's channels are subscribed to that transmitter.

Why a route can be present but not healthy

A crosspoint existing says nothing about whether audio flows. GEM reads two independent signals. The first is the subscription state the receiver reports; the labels behind it come from an optional catalog that most installs do not have, so an unresolved state is treated as no information rather than a fault — only an explicit not-connected state turns a cell red. The second is whether the named transmitter is currently discovered, which is always available: a subscription can outlive the transmitter that fed it (renamed, powered off, moved), and that is the amber case. Hover any routed cell for the reason in plain words.

Creating a route

Click an empty cell at the intersection of the TX channel (column) you want as the source and the RX channel (row) you want as the destination. The cell turns green with a checkmark and a toast confirms the route — for example Route created: SourceDevice:01 → DestDevice:01. Single crosspoints are always unicast; for multicast, route at the device level.

Clearing a route

Click a routed cell (green, amber, or red). The subscription on that RX channel is removed, the cell returns to empty, and a toast confirms the route was cleared.

Device-to-device routing

Click the cell where a TX device column meets an RX device row to route the whole device at once. This runs the same set_zone_source / clear_zone_source commands described under Zones and source routing, so it behaves identically to routing from a macro:

• Routing: the receiver's RX channels are paired in order with the transmitter's TX channels, up to whichever device has fewer. The toast reports which path was taken — (multicast) or (unicast) — because this is the only route path that builds a shared multicast flow.
• Clearing: click a dark-blue (fully routed) intersection. This removes every subscription on that receiver, not just the ones from the clicked transmitter. If the receiver is also fed by other transmitters, GEM names them and asks for confirmation first.
• A cell shows … while its route is in flight and ignores further clicks until it settles. The matrix reloads its route list when the command returns.

tip

Use device intersections for whole-endpoint source switching (and to get multicast); use channel crosspoints for asymmetric patching — a single channel, a swapped stereo pair, or two transmitters feeding one receiver.

Collapse and expand

Click a device name (a TX column header or an RX row header) to collapse or expand that device's channels:

• Collapsed TX device: its channel columns are hidden, narrowing the matrix. The arrow icon on the header rotates to indicate the collapsed state.
• Collapsed RX device: its channel rows are hidden, shortening the matrix.
• Auto-behavior on load: when the page (re)loads, devices that have at least one active route are expanded; devices with no active routes are collapsed, so the routes already in use are what you see first.
• Auto-expand on new routes: a collapsed device that gains its first route — for example patched from Dante Controller or a macro while the page is open — is expanded automatically so the new route is visible. Devices you collapsed that already had routes stay collapsed.

tip

On networks with many multi-channel devices, collapse the ones you are not patching to keep the matrix readable. Click the header again to expand.

Real-time updates

The matrix reacts to four kinds of events from the driver:

Event	Behavior
Device discovered	A newly found Dante device is added to the matrix as discovery runs.
Device details changed	A device already on screen changed its IP address, MAC, model, sample rate or channel names — a DHCP move, or a rename in Dante Controller. Its row in Discovered Devices and its matrix tooltip update in place. The event fires once per change, not once per scan, so a device sitting still produces no traffic.
Device offline	A device absent from several consecutive scans is removed from the matrix (see the note below).
Subscription change	A route created or cleared by another application (for example Dante Controller) is reflected on the matrix. If the route involves a collapsed device that previously had no routes, that device is expanded so the change is visible. When conmon multicast reaches the GEM host, the changed device's own change nudge triggers an immediate re-check and the matrix updates within a second or two; a safety-net poll re-checks every sixty seconds behind it, purely to recover from a lost nudge packet. Without multicast adjacency the driver detects the silence (no conmon heartbeats) and polls every five seconds instead — or every thirty when it also has to fall back to per-receiver browses. Events fire only when the route list actually changed, so background network chatter causes no matrix churn.

Offline devices are pruned automatically

A device that stops responding to discovery is removed from the matrix on its own. Because mDNS is lossy, the driver waits for a device to be absent from several consecutive scans (a minute or two) before declaring it offline — a single missed scan will not make a device flap off the grid. If the device also backs a GEM zone, that zone is marked disconnected until it returns.

Zones and source routing

Beyond the channel-by-channel matrix, the Dante driver can model each receiver device as a GEM zone so that Dante endpoints participate in automation, macros, and the normal zone UI like any other output.

• sync_zones — creates one GEM zone for every discovered device that has receiver channels, under the av subsystem (falling back to audio). The zone's address is the Dante device name. Re-running is safe: existing and user-disabled zones are left alone. Each zone is stamped with dante_device, ip_address, mac_address, dante_model, rx_channels, and online attributes, plus dante_source (its current source — see below).
• set_zone_source — routes a transmitter device to a receiver zone, mapping channels 1:1 in order (for a stereo endpoint, transmitter channel 1 → OUT-L, channel 2 → OUT-R). Takes a receiver argument (a GEM zone id, zone name, or Dante device name) and a transmitter argument (a Dante device name). (These arguments are named receiver/transmitter rather than zone/source because those words are reserved command keys.)
• clear_zone_source — removes all subscriptions on a receiver zone, returning it to no source. This is receiver-wide: if the receiver was fed by more than one transmitter, every one of those routes is dropped.
• refresh_zone_sources — re-reads every zone's current source from the network and updates its dante_source attribute. This also happens automatically when a subscription change is detected (for example a route made in Dante Controller).

Transmitter devices — the available sources — are listed by the get_sources command.

Argument dropdowns

When you run these commands from the device command panel or a macro step, the arguments populate from live discovery rather than free text: transmitter / tx_device offer the discovered transmitters, receiver / rx_device offer the synced receiver zones, and the plain device argument on the info and naming commands offers every discovered Dante device. The lists refresh from the driver each time the picker opens, so a newly powered-on device appears without a page reload.

note

A receiver's current source — like the matrix's route list — is normally read straight from the device: one batched direct read covers every zone. If a device's address isn't cached (or the direct engine is unavailable), the driver falls back to a netaudio subscription query scoped to that device; netaudio does not populate the receiver name in its subscription lists, so the driver fills it in itself. Either way, a receiver whose channels carry no source reports an empty dante_source.

Multicast flows

set_zone_source routes multicast-first. Before subscribing the receiver, the driver creates a shared multicast transmit flow on the source for the channels being routed, then subscribes the zone to it. A multicast flow is transmitted once and joined by any number of receivers, so routing one source to many zones consumes a single flow on the transmitter instead of one unicast flow per receiver — Dante transmitters have a limited number of unicast flow slots (commonly 32), and one-to-many routing (paging, whole-home audio) exhausts them quickly without multicast. Repeated set_zone_source calls to the same source reuse the same flow rather than accumulating duplicates, and a source's flow is removed automatically once no receiver still joins it.

set_zone_source is the only routing path that builds a multicast flow — from a macro, from the device command panel, or from a device intersection on the matrix. Single channel crosspoints on the matrix always create a plain unicast subscription.

This is transparent: on any device or network path where a multicast flow can't be established — the transmitter is offline or undiscovered, the bundled direct engine is unavailable, or the transmitter rejects the flow — the driver silently falls back to the original unicast subscription, so the route still takes effect exactly as before. Multicast flows are only created on the direct-IP fast path; a route that has to fall back to the netaudio browse path is always unicast.

To force unicast for a point-to-point route where continuous multicast traffic is undesirable, set the Force Unicast Routing attribute (force_unicast) on the zone, or on the Dante controller device to opt out every zone at once. (Multicast is efficient one-to-many but assumes IGMP snooping is configured on the switch fabric — standard for Dante deployments.) The journal records which path each route took: dante routed source … (direct, multicast) or … (direct, unicast).

Channel and device names

The matrix page shows whatever names the devices advertise and routes existing channels. Renaming and locating devices is available as driver commands (usable from macros or the device command panel):

• get_channel_names — list a device's TX and RX channel names. Confirm exact names here before routing — channel names are case-sensitive on Dante. (get_device_info returns the same names plus IP, MAC, model, and online state.)
• set_channel_name / reset_channel_name — rename a channel (type tx or rx), or reset it to the factory default.
• set_device_name / reset_device_name — rename a device, or reset it. Renaming a device changes the name routing keys on; re-run sync_zones afterward so zone addresses stay aligned.
• identify_device — blink a device's identify LED to locate it physically.

Troubleshooting

No devices discovered

1. Confirm a dante device exists in System → Devices and is Enabled.
2. Confirm GEM's Python environment is provisioned — if the bundled netaudio tool is missing, the Dante device cannot connect and nothing is discovered. Re-run the GEM installer and choose the Python/dependencies step, then reload the Dante device.
3. Confirm the Dante devices are on the same network as the GEM server, powered on, and initialized.
4. Confirm multicast reaches the GEM host: disable IGMP snooping on intermediate switches or place GEM on the same VLAN as the Dante devices. Devices that show in Dante Controller but not in GEM almost always indicate blocked multicast.
5. Click Refresh after fixing the path.

Route not taking effect

1. Check the cell colour first — amber (?) means the transmitter is not on the network, red (!) means the receiver rejected the subscription. Hover the cell for the specific reason.
2. Confirm the exact channel name (case-sensitive) against Dante Controller.
3. Confirm the TX and RX devices use compatible sample rates and share a clock domain.
4. Confirm the channels are not locked by Dante Controller or another application.
5. Confirm sufficient network bandwidth for the added flow.

A route shows amber (transmitter not discovered)

The receiver still holds a subscription naming a transmitter that discovery cannot see. Usual causes: the transmitter is powered off or unplugged, it was renamed (Dante subscriptions bind to the device name, so a rename orphans them), or it is on a network segment GEM can no longer browse. Power it back on or restore the name and the cell returns to green on the next refresh; otherwise clear the crosspoint and re-route from the transmitter's current name.

Subscription changes are slow to appear

Changes made elsewhere normally appear within a second or two — each Dante device multicasts a change nudge on 224.0.0.231:8702 the moment its routing changes, and GEM re-checks immediately. If updates consistently take about five seconds, conmon multicast is not reaching the GEM host (the driver detects the missing 1 Hz heartbeats on 224.0.0.233:8708 and falls back to fast polling) — fix the multicast path (IGMP snooping / VLAN adjacency) to get wire-speed updates. Changes that consistently take about thirty seconds mean the direct engine is unavailable and every check is falling back to slow per-receiver browses — re-run the GEM installer's Python/dependencies step, then reload the Dante device. The journal says which path caught each change: dante subscription change detected via multicast or via polling. It also logs every heartbeat-health transition — dante conmon heartbeats detected - subscription poll relaxed to safety net when the multicast path starts working, and dante conmon heartbeats not reaching this host - fast polling for subscription changes when it stops — so a grep of the journal shows exactly when adjacency was gained or lost.

Related documentation

• Devices — creating and enabling the dante device record.
• AV Zones and AV Sources — GEM's audio-zone model. The channel matrix operates at the Dante network/transport level; sync_zones additionally projects Dante receivers into GEM zones so they can be driven from automation.