Start Here: What Does the Device List Actually Show?
Three different symptoms get described as "Dante Controller can't see my device", and they have different causes:
| What you see | Meaning |
|---|---|
| Device absent entirely | Discovery is not reaching it — NIC, subnet or switch |
| Device name shown in red | Discovered, but Dante Controller detected a fault — usually IP config or failsafe |
| Device present, no Clock Status / Device Info | Partial communication — often firewall or a second NIC |
A red name is much better news than an absent device, because it proves discovery works. Double-click the red name and Dante Controller will tell you what it objects to.
Before anything else: hit refresh and wait a full 60 seconds. Discovery is not instantaneous, and a surprising number of "missing device" reports resolve themselves in that minute.
Cause 1: More Than One Network Interface
This is the most common cause, and the least obvious.
Dante Controller binds to one interface. If your laptop has Ethernet plus Wi-Fi, or two Ethernet ports, or a virtual adapter from VPN or virtualisation software, discovery can bind to the wrong one.
Fixes, in order of preference:
- Select the right interface explicitly. Dante Controller has an interface selection button in the Network View toolbar. Use it before assuming anything is broken.
- Disable every interface you are not using. Turn Wi-Fi off. Disable the virtual adapters. Leave the Dante interface as the only one running.
- If you must keep two wired interfaces, put them on different subnets. Two NICs on the same subnet produces unpredictable routing, and Dante is unusually sensitive to it.
On macOS, additionally set the Dante interface to the highest priority in network service order.
The tell for this one: the device is visible from a colleague's laptop but not yours, on the same switch. That is almost always a local NIC issue, not a device or network issue.
Cause 2: IP Addressing and Subnet Mismatch
This is what produces the red device name and the warning "Detected devices with addresses that do not match the subnet of the local Dante interface".
What the addressing should look like
| Setup | Expected range |
|---|---|
| Standalone network, no DHCP server | 169.254.x.x (Link Local) |
| With a DHCP server | Whatever that server issues |
| Secondary (redundant) network using Link Local | 172.31.x.x |
Use the Device Info tab to see actual IP addresses.
The three ways this goes wrong
1. Someone set a static IP on a device. The device is on 192.168.1.50 while everything else self-assigned into 169.254.x.x, so it appears but cannot be reached. Fix by temporarily setting your computer's IP into the same subnet as the stranded device, connecting to it, and setting it back to DHCP/automatic.
2. DHCP and Link Local are mixed on the same network. Some devices got addresses from a DHCP server and others fell back to Link Local, so they are on different subnets and cannot see each other. Pick one scheme and apply it to everything, including the computer.
3. There is a DHCP server nobody knows about. A router someone plugged in, or a PC running one. This produces the maddening version where addressing was fine yesterday. If addresses look inconsistent, go looking for a second DHCP server before anything else.
General rule: you should not normally need static IPs on a Dante network at all. If you use one, it must be in the same subnet as everything else.
For a device hiding on a completely unknown static subnet, Audinate publishes a recovery procedure — that is the case where you cannot guess the subnet to join.
Cause 3: The Switch
IGMP snooping without a querier. Dante uses multicast for discovery and clock. On a managed switch with IGMP snooping enabled but no querier, multicast gets filtered into oblivion and devices vanish.
The rule is: exactly one device must be the querier. Zero queriers breaks discovery; two queriers fight. If you have IGMP snooping on, verify the querier situation — and if nobody can tell you which device is the querier, that is itself the answer.
ACLs on the switch can block Dante's traffic — worth checking on a corporate network where the AV VLAN was configured by someone else.
VLANs. If the computer is not on the Dante VLAN, it will not see the devices. Under Dante Domain Manager or Dante Director, the computer must be in the same VLAN as the devices.
Cross-subnet does not work by default. A receiver on 192.168.0.0/24 and a controller on 192.168.10.0/24 will not find each other unless routing has been explicitly set up for it. Dante Controller correctly reports that the device is not on its network — the software is right, the network design is the problem.
Additionally, if the computer running Dante Controller has a self-assigned (Auto IP) address, it may fail to detect devices in other subnets even where routing exists.
Cause 4: Firewall, Antivirus and Services
Dante uses unusual port numbers, which is exactly the profile that security software blocks by default.
- Dante software adjusts the built-in Windows Firewall automatically, but third-party firewalls and internet security suites are not handled.
- Test by disabling the antivirus once. If that fixes it, add Dante Controller and Dante Virtual Soundcard to the trusted applications list rather than leaving protection off.
- Check that the Dante Control and Monitoring service (ConMon) is running in Services, and restart it if not.
Cause 5: The Basics
Worth confirming before deep diagnosis, because they are free to check:
- Cable plugged in, activity lights flashing rapidly. If the link LED at the socket is dark, the cable or port is dead and no amount of software configuration will help.
- Dante Controller is current. An old version against newer firmware causes odd behaviour. Reinstalling also rules out an OS-update-related problem.
- Devices previously managed by Dante Domain Manager may need their domain credentials cleared after a reset.
An Isolation Test That Settles It
When you are out of ideas, duplicate the network path as closely as possible: put the computer and the device on the same switch — ideally by inserting a small unmanaged switch with only those two things on it — and see whether the device appears.
If it appears in isolation, the fault is in the production network: VLAN, IGMP, ACL, or a second DHCP server. If it does not appear even there, the fault is the device, the NIC, or the addressing.
This single test cleanly separates "network problem" from "device problem", which is worth ten minutes because those two lead to completely different next steps — and completely different people to talk to.
Diagnostic Order
- Refresh and wait 60 seconds
- Interface selection — right NIC chosen? other NICs disabled?
- Device Info tab — what addresses do you actually see?
- Red name? Double-click it and read the reason
- Link Local vs DHCP — is everything on the same scheme?
- Second DHCP server on the network?
- Firewall / antivirus — disable once to test
- ConMon service running?
- Switch — IGMP querier, ACLs, VLAN
- Isolation test — same switch, nothing else
Where This Fits with Show Control
Dante carries the audio; it does not start the show. In an exhibition hall the control system still has to power the amplifiers, select sources, set levels on the DSP and trigger playback — and that happens over TCP, UDP, HTTP or serial, not over Dante.
Being straight about scope: SoftControl does not route Dante audio and does not replace Dante Controller. What it does is sit above the audio network — one "open the hall" action that powers displays, wakes the media PCs, recalls the DSP preset and starts playback, instead of an operator touching four systems in the right order.
If your DSP is a Biamp, QSC or Symetrix unit, it almost certainly accepts serial or TCP control commands alongside its Dante audio — that control path is the one a show controller uses.