The Ghost in the Machine: When Your Own Virtual Soundcard Won’t Show Up
A show-day field report on Dante, dual NICs, and the address that lied.
Cold open
Twenty minutes to a live match feed. SportMonks dashboard glowing in the corner, scores pipeline armed, the whole audio fabric staged and ready. Eight Dante devices on the network — an AudioCtrl ANX4, an AQL64, an Analog Way Picturall, a Q-SYS Core 110f, a Yamaha Rio3224-D3 — all of it humming. And the one device I actually need to route to won’t show up.
My own Dante Virtual Soundcard. Running on this very machine. Invisible in Dante Controller.
If you’ve never watched a device that is physically inside the computer you’re staring at fail to appear in the software also running on that computer, let me tell you: it does something to your blood pressure. The card is started. The interface is bound. The IP is set. And Controller looks right through it like it isn’t there.
This is the story of why — and it is not the reason I spent the first hour assuming.
The setup
Single engineering PC, call it RC-ENG-PC, doing double duty the way these boxes always end up doing: it’s the show control machine and it’s running Dante Virtual Soundcard (DVS) to get audio in and out of the production software. Classic small-footprint setup. One box, two jobs.
And — here’s the part that matters — two network cards. One for the internet (scores feed, dashboards, the outside world). One for the Dante audio network, which is an island with no route to anywhere.
Two NICs. Remember that. Everything that went wrong flows from those two words.
The IP schema
Here’s the world as it actually was. Two completely separate /24 subnets:
The Dante network — 10.201.200.0/24 (the audio island, no gateway, no internet):
| Device | Model | Address |
|---|---|---|
| ANX4-ab1546 | AudioCtrl ANX4 | 10.201.200.16 |
| AQL64-16c10c | AQL64 | 10.201.200.250 |
| AWMS-92d4a9 | Analog Way Picturall Pro Mark II | 10.201.200.20 |
| chi-lab-core110 | Q-SYS Core 110f | 10.201.200.19 |
| Y002-Yamaha-Rio3224-D3 | Yamaha Rio3224-D3 | 10.201.200.21 → later .213 |
| RC-ENG-PC (DVS) | Dante Virtual Soundcard | 10.201.200.21 |
The internet network — 10.201.100.0/24:
| Interface | Address | Gateway | DNS |
|---|---|---|---|
| Int.80 (Intel I226-V, 2.5GbE) | 10.201.100.80 | 10.201.100.1 | 10.201.100.1 |
And lurking in the background, because of course it was: a Wi-Fi 6E adapter (RZ616), connected. A third live interface I wasn’t even thinking about.
The Dante NIC was named — I am not making this up — “Dante.21”, statically set to match the last octet of its IP. Tidy. Looked deliberate. Was, in fact, the seed of the first disaster.
Act One: the duplicate that hid in plain sight
First symptom: DVS appeared in Controller’s Device Info tab as RC-ENG-PC, but its row was half-empty — Primary Address blank, half the columns reading N/A — and it was completely absent from the Routing grid. Five devices in the matrix; the VSC not among them.
Here’s the thing nobody tells you about Dante discovery: a device showing up in Device Info and a device being routable are two different events, powered by two different mechanisms.
- Device Info is fed by mDNS / multicast announcements. A device shouts its name across the link-local segment and everyone hears it. Cheap, broadcast, works across a lot of misconfiguration.
- The Routing grid requires Controller to open unicast communication to that device’s actual IP and enumerate its channels.
So a device that announces its name but can’t be reached at its address shows up as a ghost: name present, everything else blank, absent from routing.
Why couldn’t it be reached? Because the DVS was sitting on 10.201.200.21 — and so was the Yamaha Rio3224. A duplicate IP. Two devices, one address.
When Controller tried to talk to .21, ARP resolved it to whichever device won the fight, and a powered-up hardware Rio that’s already clocking and routing beats a software card every time. The Yamaha appeared fully. The DVS became a ghost with no address.
The fix should have been trivial: move the DVS to a free host on the same subnet. I said .30. And then I made the dumbest mistake of the whole afternoon.
Act Two: the wrong turn (a confession)
I changed the wrong octet.
Instead of 10.201.200.30, the Dante NIC went to 10.201.204.21 — different third octet, with a gateway of 10.201.204.1 bolted on for good measure. With a /24 mask, .204.x and .200.x are two different planets. The PC was no longer on the audio network at all.
The entire device list went red.
Red, in Dante Controller, is the network equivalent of seeing someone across a canyon. mDNS is still crossing the switch at layer 2, so Controller hears every device’s name — but it can’t open a unicast connection to anything on a different subnet, so every single device flips to “I can see you and I cannot talk to you.” Hardware that had been green for years went red because I’d moved the PC off its network, not because anything was wrong with the hardware.
Two sins in one move:
- Wrong subnet —
.204instead of.200. - A second default gateway — on a dual-NIC Windows box, two default routes is its own special flavor of chaos.
I put it back the right way:
IP: 10.201.200.21
Mask: 255.255.255.0
Gateway: (blank) ← the Dante NIC must NEVER have a gateway
DNS: (blank)
The hardware fabric snapped back to green. And — small mercy — the Yamaha had drifted to 10.201.200.213 in the meantime, so the original .21 collision was gone. One problem closed itself.
But the VSC? Still a ghost. Still N/A. Still absent from routing. And now the hardware was perfect, so I couldn’t blame the network anymore.
This is the moment the real problem started.
Act Three: the dual-NIC truth nobody warns you about
Here’s what I’d been ignoring: Windows is multi-homed, and multicast doesn’t care about your subnets.
Dante discovery runs on mDNS multicast (224.0.0.251, UDP 5353). That traffic is link-local — it isn’t routed by subnet, it’s emitted on whichever interface Windows decides is “primary.” And the way Windows picks “primary” by default is: whichever interface holds the default gateway wins.
My internet NIC held the gateway. So Windows was happily firing Dante’s discovery queries out the internet card, into a network with zero Dante devices, hearing nothing back. Meanwhile the actual audio fabric sat silent on the other NIC.
That’s why, earlier, I’d found that disabling the internet NIC made the VSC magically appear. I thought it was a fluke. It wasn’t — it was me accidentally forcing the Dante NIC to become primary by removing its only competition.
And the cruelest detail: reaching the remote hardware worked, because that traffic eventually found its way out the right card via the direct subnet route. But reaching the local DVS — a device living on the same PC — is a host-talking-to-itself path, and Windows resolves that via the primary interface too. Primary was wrong, so the machine couldn’t find its own soundcard.
The fix is to stop letting the gateway decide. Interface metrics:
- Dante NIC → metric 1 (lowest wins primary)
- Internet NIC → metric 99
- Wi-Fi, Bluetooth, everything else → high
Lowest metric becomes the preferred path for local multicast, while the internet NIC keeps its gateway and stays the only route to the outside world. Best of both.
I set them. I verified with PowerShell:
Find-NetRoute -RemoteIPAddress 10.201.200.19 |
Select-Object IPAddress, InterfaceAlias, NextHop
IPAddress InterfaceAlias NextHop
--------- -------------- -------
10.201.200.21 Dante.21 0.0.0.0
Source address 10.201.200.21, out Dante.21. The operating system was now doing exactly the right thing. Routing: perfect. Metrics: perfect. NIC binding: perfect.
The VSC was still a ghost.
I rebooted. Still nothing.
Act Four: the address that lied
I gave up on the local box and opened Dante Controller on a second PC to look at the fabric from outside. And that machine finally told me the truth, in the form of an error dialog I should have chased two hours earlier:
Dante Controller has discovered an address for device ‘RC-ENG-PC’ that does not match the subnet configuration of the local Dante interface. Resolved device address: 10.201.100.80
There it was. RC-ENG-PC was advertising itself at 10.201.100.80 — the internet address. Not the .200.21 it was actually bound to. The DVS panel said .200.21. The routing table said .200.21. But the name resolution was handing out the internet IP.
I ran the resolve directly to confirm:
Resolve-DnsName -Name "RC-ENG-PC.local" -Type A
Name Type TTL IPAddress
---- ---- ---- ---------
RC-ENG-PC A 1200 10.201.100.80 ← internet NIC
RC-ENG-PC A 1200 10.201.200.21 ← Dante NIC
Two A-records. One hostname. Both interfaces.
This is the root cause, and it’s the thing about multi-homed Dante that will quietly ruin your day: the mDNS responder registers the hostname against every active interface’s IP. Fixing the routing metric changes which NIC Windows prefers — it does not stop the responder from publishing the other addresses. So RC-ENG-PC.local resolved to both .100.80 and .200.21, and a remote Controller had a coin-flip’s chance of grabbing the internet address, choking on the subnet mismatch, and showing the device as a ghost.
The OS layer and the advertisement layer are different problems. I’d spent an hour perfecting the first while the second sat there lying to the whole network.
Act Five: the things that didn’t work (so you can skip them)
In the spirit of an honest field report, here’s what I tried and how it went:
- Disable the internet NIC entirely. Works instantly — VSC appears, everything green. Useless to me, because I need the internet up for the scores feed during the show.
- Firewall-block mDNS (UDP 5353) on the internet NIC only. The right idea — silence the responder on
Int.80so it can’t publish.100.80, while Dante keeps announcing normally. But:New-NetFirewallRuleneeds an elevated PowerShell, and my first attempts failed silently because the terminal wasn’t running as Administrator. Lesson: if rule creation returns nothing fromGet-NetFirewallRule, it didn’t run — check elevation before you trust it. - Restart the Bonjour service to force re-registration:
Restart-Service "Bonjour Service" -Force→ Cannot find any service with service name 'Bonjour Service'.Plot twist: on this Windows 11 box, classic Apple Bonjour wasn’t the responder at all — modern DVS leans on the built-in Windows mDNS stack. So the service I was trying to bounce didn’t exist under that name, which is also why suppressing it had been so awkward. You can’t restart what isn’t there.
Every one of these is a legitimate fix in the right circumstances. None of them is something you want to be discovering for the first time with a clock ticking toward kickoff.
The solution
There are two answers, and which one you reach for depends entirely on whether you’re on a clock.
The show-day answer (do this when there’s a kickoff)
Stop fighting the multi-homed box. Route from a clean machine.
Leave the engineering PC exactly as it is — internet up, DVS started (a stopped card advertises nothing, check this first), bound to the Dante NIC. Then run Dante Controller from a second computer that’s single-homed on the 10.201.200.0/24 audio network. That machine resolves the DVS the correct, single-address way and is completely immune to the local box’s dual-advertisement mess.
It sidesteps the entire problem instead of wrestling it live. Internet stays on the eng PC, audio routing happens from the clean box, the show goes to air. This is the move. Pride is not a production value.
The permanent answer (do this when nothing is on fire)
Make the multi-homed PC stop advertising the wrong interface, once and for all. In rough order of cleanliness:
- Pin the metrics (Dante NIC = lowest) so the OS layer is correct — necessary but, as we learned, not sufficient on its own.
- Suppress mDNS on the internet NIC so the responder physically cannot publish the internet address to the Dante segment. Firewall rules blocking UDP 5353 on that interface (from an elevated prompt), or binding the responder to a single interface, depending on which mDNS stack the box is actually running.
- The Audinate-blessed answer, honestly: don’t run Dante Controller and DVS and internet on one multi-homed machine if you can avoid it. A single NIC dedicated to Dante makes this entire article impossible. The dual-NIC setup works, but only with strict subnet separation, explicit interface binding, gateway on the internet side only, and the mDNS publishing under control.
What I’d tattach to the rack as a sticky note
- Device Info ≠ routable. A name in Device Info is an mDNS announcement. Routing needs reachable unicast. A ghost (name present, address blank, missing from the grid) means “heard, can’t reach.”
- Red = different subnet / unreachable. If everything goes red at once, you moved the PC, not the devices.
- The Dante NIC gets NO default gateway. Ever. Two gateways on one box is its own disease.
- Change the host octet, not the network octet.
.200.30, not.204.21. (Ask me how I know.) - On multi-homed Windows, the gateway NIC is “primary” for multicast unless you override it with interface metrics. Dante NIC = metric 1.
- Metrics fix the OS routing. They do NOT fix mDNS publishing. The responder still advertises every interface’s address against the hostname.
Resolve-DnsName RC-ENG-PC.localreturning two IPs is the smoking gun. - The OS can be 100% correct and discovery still broken. Routing layer and advertisement layer are separate. Diagnose both.
- Re-running a diagnostic script changes nothing. Diagnosis is not a fix. Read the output of the command you ran — silent failures (no elevation, wrong service name) will happily let you believe you fixed something you didn’t.
- When the clock is real, isolate the function to a clean box. Debug the cursed machine after air.
Filed from behind a flight case, twenty minutes that felt like two hours, with the match still safely on the air — from the second PC.





























































interesting interpretation of music










