OBS Application Audio Capture Runbook for Cloud OBS and Backup Mixes

The direct answer

Application Audio Capture is the right OBS tool when one program needs its own fader, mute, routing decision, or emergency cut. It is not a reason to capture desktop audio, a window, and the same app source all at once. Build one owner for each sound, then test the mix that reaches StreamableRun and the mix that a viewer actually hears.

OBS documents Application Audio Capture for Windows 10 version 2004 and later and Windows 11. OBS 30.1 also lets Window Capture and Game Capture include audio. Those options make it much easier to isolate a game, a browser call, a music player, or a replay tool, but they also make duplicate audio easy to create if global Desktop Audio remains active.

For a Cloud Hosted OBS workflow, use the local machine to make a clean contribution mix. Send that stable source into StreamableRun. Keep public scenes, fallback media, destinations, and the producer handoff in Cloud OBS so a local app crash does not turn into a public scramble.

Choose one capture owner

Start by listing every sound a viewer should hear: host microphone, field microphone, game or camera audio, remote guest, alert, music, and producer talkback. Give each one a single capture owner. A host mic might be an Audio Input Capture source. A guest browser might be an Application Audio Capture source. A camera on a capture card may use its linked audio device. The producer talkback should normally stay off the program mix.

The common failure is accidental ownership overlap. Global Desktop Audio sees the game. Application Audio Capture sees the game too. A capture card also has the camera mic active. The meter looks healthy, but the audience hears a flange, echo, or loudness jump. Muting one source does not fix the other because both were legitimate captures.

Write the source name as a sentence, not a device nickname: Game Audio Program, Guest Call Program, Host Mic Program, Producer Talkback Monitor Only. A frantic operator should be able to mute the right thing without remembering that Device 2 is actually the guest laptop.

• One program sound should have one capture owner.
• Disable global Desktop Audio when per-app sources replace it.
• Keep producer talkback on monitoring, not on the public program bus.
• Name sources by role and destination, not by USB port.
• Treat a source that is visible in the meter as unproven until a viewer device hears it.

Windows and macOS do not use the same path

On current Windows builds, the OBS Application Audio Capture source can target an application, and OBS recommends choosing an appropriate matching priority. A changing browser title is a good reason to match by executable name rather than title. OBS also notes that some applications will need a virtual audio cable because they do not cooperate with the beta capture path.

On macOS 13 or later, OBS documents the macOS Audio Capture Source and macOS Screen Capture Source for desktop or application audio. That is a separate operating-system path; do not copy a Windows virtual-cable recipe onto a Mac just because a video showed it. Check which source exists on the exact machine before call time.

Linux operators should verify the PulseAudio or ALSA route and device naming in rehearsal. The production rule is consistent across platforms: a local sound route should be explicit, restartable, and easy for a remote producer to understand from the scene names.

Build scenes around sound states

Do not make every Cloud OBS scene inherit every local sound. Build a small set of audio states. Main Program carries host, field, game or camera, and the approved guest. Guest Hold keeps the guest picture available but removes their audio if they need a private reset. Privacy or BRB uses safe music or no program sound. Technical Fallback has its own known-good audio instead of reusing a broken live source.

If a local OBS sends the full program to StreamableRun, rehearse scene changes there and give the cloud producer equivalent public fallback scenes. If Cloud Hosted OBS is doing the final switch, label which source carries which audio and keep the remote producer from guessing. A video source can be present while its audio belongs to a different local source.

A good producer handoff says more than 'audio is okay.' It names the main source, the guest source, the fallback audio, the talkback route, and who can change each one.

• Main Program: normal public mix.
• Guest Hold: guest picture without accidental private audio.
• BRB or Privacy: safe audio that does not depend on a field device.
• Fallback: independent slate or clips audio for an ingest loss.
• Return: test meters and viewer preview before bringing the live source back.

Run the duplicate-audio drill

Before a public stream, play one identifiable sound from each application. Mute it at its assigned OBS source. If it is still audible, there is another owner. Find it before continuing. Repeat for the capture card, browser guest, alert tool, music player, and any camera that embeds audio over HDMI or USB.

Then test a source restart. Close and reopen the captured browser or game. Verify the source reconnects, its meter returns, and no stale desktop capture takes over. If an app has a changing window title, test the behavior after a tab or call title changes. This is where executable-name matching can save a real show.

Finally, watch the StreamableRun ingest and a normal platform preview. Local headphones are useful but not final proof; they can be monitoring a different path from the one being published.

• Solo each program source for a five-second identification check.
• Mute it and confirm the sound truly disappears.
• Restart the source application and confirm it returns once.
• Switch to fallback, then back, while listening on a viewer device.
• Record the source name and recovery action in the producer packet.

Use virtual cables as a deliberate exception

OBS warns that some applications may not work with Application Audio Capture and documents a virtual-cable workaround. That workaround can be useful, especially for an app with a stubborn audio engine, but it creates another device that must survive restart, sleep, and handoff. Treat it like infrastructure, not a clever trick.

Label both ends clearly. The application outputs to the virtual cable; OBS captures the cable output. Do not also leave that app in Desktop Audio. Verify whether the operator can still hear it locally and whether their monitoring choice causes a feedback loop. A virtual cable is often the correct answer, but only after the native source path has been tested.

Keep the fallback simple. If a virtual route breaks during an IRL segment, a Cloud OBS producer should be able to cut to a safe scene, tell the field operator which app to restart, and return only after the published preview is clean.

How StreamableRun fits the recovery plan

Use StreamableRun as the line between local experimentation and the public show. A local OBS machine can isolate app audio, capture cameras, and assemble a contribution feed. StreamableRun receives that feed, while Cloud Hosted OBS keeps the destination configuration, public fallback scenes, clips, overlays, and remote producer controls in an operating layer that does not disappear when a Windows app freezes.

Give the producer a short decision tree. If one app has no sound but video is fine, keep the audience on a safe scene or bring up a lower-third while the local operator repairs the source. If duplicate sound appears, mute the designated program source and locate the extra owner. If the whole local mix fails, switch Cloud OBS to fallback or a backup ingest rather than debugging live in front of viewers.

The goal is not to build the fanciest audio graph. It is to make the public result recoverable by someone who was not under the desk when the cables were plugged in.

• Local OBS: application isolation and source-level repair.
• StreamableRun ingest: stable handoff from the local mixer.
• Cloud Hosted OBS: public scenes, clips, fallback, and destinations.
• Producer: viewer-preview confirmation and documented recovery decisions.
• Backup: alternate ingest or safe media scene if the local machine needs a restart.

Other resources

Use these current OBS references to verify application capture behavior on the operating system you will actually use, then rehearse the entire local-to-cloud route before a live event.