Dante Audio to Cloud OBS: A Safe Handoff Plan for Live Production

The direct answer

Dante can be a clean way to get a venue or studio mix into a live show, but it is not an internet contribution protocol and it is not a replacement for the program path. Treat it as the local audio layer: microphones and a console feed a named Dante subscription, that subscription reaches the capture or production machine, and that machine provides one tested audio source to Cloud Hosted OBS. StreamableRun then owns the program scenes, fallback, destinations, and producer handoff.

The important choice is whether the show needs a stereo program feed, a mix-minus return, isolated tracks for a local record, or all three. Do not begin by clicking routes until the audio owner can describe which one each listener needs. A DJ needs to hear a cue mix. A remote guest needs a return that excludes their own voice. The public program needs a stable, intelligible mix. Those are different feeds, even when they originate on the same console.

Audinate documents that Dante audio can use unicast or multicast, with unicast as the normal default. That is useful context, not permission to guess at switch settings during a show. Make the simple route work first, name it clearly, and only add multicast or more complicated networking when the audio system owner has a real routing requirement.

Draw the signal path before the first patch

Write the path in plain language: wireless receiver to console, console program bus to Dante transmitter, Dante subscription to the production machine, audio input source in Cloud OBS, then program output to each destination. Put a person next to every boundary. The A1 owns gain and console routing. The producer owns the Cloud OBS scene. The destination owner verifies that viewers hear the public mix. That little map prevents three people from changing the same fader when something sounds wrong.

Use names that describe purpose rather than hardware history. `Program-Stereo`, `Host-Mic-ISO`, `Guest-Return`, and `Venue-Ambience` make a handoff possible. `Dante-1` and `Line-3` only help the person who built the rack. If the operating system exposes the Dante device as multiple channels, document exactly which pair Cloud OBS receives and which channels are intentionally unused.

Keep the public program route narrow. A large multichannel patch can be valid for recording, but it gives a live producer too many ways to select the wrong pair. Start with the approved stereo program input. Add isolated channels only where a recorder or an explicitly assigned audio operator is using them. The audience should not be the first place you discover that left and right were swapped or that a spare return channel reached the stream.

• Name feeds by listener and purpose.
• Assign console, Cloud OBS, and destination owners.
• Document the approved stereo pair.
• Keep optional isolated tracks outside the public program path.

Build a mix that survives a scene change

A venue mix is not automatically a livestream mix. Room PA, host microphone, walk-in music, playback, and crowd microphones can have very different priorities once they reach phones and earbuds. Ask the audio operator for a program-oriented feed, then listen to it at the point where Cloud OBS receives it. A meter moving at the console proves that one layer is alive; it does not prove the source is active in the right scene or that the destination carries useful speech.

OBS documents that an audio capture device can be configured as a source, and it warns that capturing the same device both globally and as a scene source can create echo. Pick one ownership model for the program feed. For a live show, a scene source is often easier to reason about because it can be visible in the scene collection, but the exact choice matters less than avoiding duplicate capture. Label the source as the public mix and keep it enabled only where the scene design intends it.

Make a dedicated safety scene with the same approved program audio or a deliberately chosen fallback bed. A beautiful BRB card with dead air is not a fallback. If the field camera or NDI picture drops, the producer should be able to move to the safety scene without rebuilding the audio route. Test that transition with real speech, not with a silent tone generator.

• Create a program mix for viewers, not only for the room.
• Capture a device once in the public program chain.
• Put tested audio in Main, Backup, and BRB scenes.
• Listen after the Cloud OBS source, not only at the console.

Handle talkback and mix-minus on purpose

Mix-minus is a routing decision, not a button that makes remote communication safe. If a guest hears their own return late, they will talk over themselves or mute the wrong thing. Build a named guest return that contains host, playback cues, and producer talkback as appropriate, while excluding the guest microphone. The guest return should be tested on the actual call device before program time.

Do not send public program audio back to every participant by default. The public program can include delay, browser audio, music, and a guest’s own voice. Keep producer coordination, guest return, and public mix separate in the runbook even if the console makes them easy to route. It gives the team a way to isolate feedback without touching the audience feed.

For StreamableRun, use Cloud Hosted OBS as the program boundary, not as a reason to hide audio routing. The producer can keep the show live, switch to a backup scene, and protect destinations while the local audio owner restores an input. A producer should know which scene retains program audio and which person is allowed to alter Dante subscriptions; they should not be asked to hunt through an audio-network control panel mid-show.

• Make guest return a named mix-minus route.
• Keep talkback separate from program audio.
• Test on the actual remote-call device.
• Limit Dante routing changes to the assigned audio owner.

Preflight with a short, repeatable test

Run a five-minute rehearsal with a host mic, a music cue, and one remote-return check. First confirm that the Dante subscription is present. Then speak into each expected microphone, bring music up and down, switch Cloud OBS between Main and Backup, and listen from a viewer-side device. Record what the operator sees: source meter, Cloud OBS mixer, destination preview, and headphones. Do not call the path healthy because one of those four looks good.

Use the rehearsal to set a practical escalation rule. A missing Dante source is a local audio-layer incident. A healthy Cloud OBS meter but silent destination can be a scene or output issue. A healthy destination with a complaint from one guest can be a return-path issue. Naming the layer stops the field streamer from changing an SRT encoder because the venue console lost its subscription.

Audinate’s current port reference is useful when an IT owner needs to approve a network design, but do not paste a port list into a public chat and call the venue ready. Confirm access with the venue network team before load-in. Keep the production machine on the approved network, avoid casual Wi-Fi changes, and preserve a simple local analog or USB backup input when the show genuinely cannot wait for network investigation.

Give the producer a failure plan

The producer card needs only six lines: approved program source name, expected meter behavior, backup input, safe scene, audio owner, and the viewer-side verifier. It should not contain network passwords, console admin access, or a list of every channel in the building. The goal is to make the first response boring: preserve program video, switch to approved backup audio if necessary, tell the audio owner what is missing, and verify the public destination after the change.

If the Dante feed vanishes, do not repeatedly reselect devices in a live Cloud OBS scene. Move to the known-good safety plan while the audio owner checks subscription, device state, and network conditions. If an analog or USB backup is present, bring it in deliberately and tell the destination verifier what should change. A temporary mono backup with understandable speech is better than a public show where everyone is randomly repatching audio.

After recovery, write down the cause in operational terms: subscription changed, capture device disappeared, duplicate source caused echo, or destination mix was wrong. That record is more useful than ‘audio issue fixed.’ It tells the team what to rehearse next time and helps keep the Cloud OBS workflow a calm production boundary rather than another place to improvise.

• Preserve video and switch to an approved audio fallback.
• Do not expose credentials in the producer card.
• Verify public playback after every audio cutover.
• Record the layer and cause after recovery.

Other resources

Use Audinate’s current support material to verify network behavior with the audio and IT owners, and use the OBS guides to confirm how the production machine captures and meters the final source. Those documents explain product behavior; your show file must still document the specific console bus, subscription names, fallback input, and communication owner for the event.