OBS Studio has a feature when setting up the Video Capture Device.
Audio Output Mode - Capture audio only, Output desktop audio (Directsound), Output desktop audio (WaveOut)
This routes the audio capture direct to a recording or stream (or) routes it through a desktop mixer.
If routed direct to recording or stream then the VU meter for the sounds source remains the same as the Video Capture Device in the Mixer panel. - however the audio by default remains silent during monitoring a recording or stream.
If routed to desktop (directsound or waveout) the VU meter for the Video Capture Device stops working and goes dead, because the sound is re-routed through the desktop / waveout control in the Mixer and that VU meter will register the Video capture Device activity.
The sound will only be heard while recording/streaming if the 'Advanced Audio Properties' gear wheel has [Audio Monitoring] set to (Monitor and Output) for the selected routed path - Video Capture Device or Desktop (Directsound / waveOut) -AND-
Controls - Settings - Audio (down the vertical Icon widgets) - opens and displays Sources -AND-
The Desktop Audio Device is "not" Disabled / Default - it must be set to a destination like speakers ect..
Monitoring is a separate function from capture and routing to a path, its somewhat confusing.
With 'capture only' the Video Capture Device - VU meter will work
With 'Audio Monitoring' set to Monitor and Output, and the Audio set to an enabled output device
Both the device VU meter will work and you will be able to hear the sound during a recording or streaming session.
My take on this is it is offered as a choice so that if you want to capture both the Video Capture Device audio and overlay or mix it with the sound from a desktop interactive session like Narration voice or Music, this will blend the two together and capture both as one signal in the recording or streaming session.
I thought you could do this more plainly by adding Sources creating new Items in the Mixer individually but perhaps its a legacy method that is still supported and turns up as a relic or artifact that confounds peoples use of the OBS Studio today.
1. What Audio Output Mode on a Video Capture Device actually does
You’re right that this setting controls where the capture device’s audio is injected into OBS’s audio graph.
The three modes:
1) Capture audio only
-
Audio goes directly into OBS’s internal audio engine
-
Appears as the Video Capture Device source in the Mixer
-
VU meter on that source works
-
Audio is recorded / streamed
-
You hear nothing by default (monitoring is OFF)
This is the cleanest and most modern path.
2) Output desktop audio (DirectSound / WaveOut)
-
Audio is sent out to Windows
-
Then recaptured via OBS’s Desktop Audio device
-
The Video Capture Device source no longer owns the audio
-
Result:
-
Video Capture Device VU meter goes dead
-
Desktop Audio VU meter shows activity
-
You hear audio because Windows is playing it
This is intentional—not a bug.
OBS is saying:
“That source no longer contains audio. The OS does.”
2. Monitoring vs capture (this is the key mental model)
You nailed this part:
Monitoring is separate from capture and routing
OBS has three independent concepts:
-
Capture (is the audio included in the recording/stream?)
-
Routing (which source owns the audio?)
-
Monitoring (do you hear it?)
People mentally collapse these—and OBS doesn’t help.
3. Why audio is silent in “Capture audio only”
Correct explanation, with one nuance:
This is by design to prevent feedback loops.
4. What’s required to hear monitored audio (your checklist is almost perfect)
Required conditions (cleaned up):
-
Advanced Audio Properties
-
Settings → Audio
-
Desktop Audio device
Correction 👇
“The Desktop Audio Device must not be disabled”
That is only true if:
If you’re using Capture audio only + monitoring, Desktop Audio can be:
-
Disabled
-
Unused
-
Completely ignored
Monitoring bypasses Desktop Audio entirely.
5. VU meters — why they behave “weird”
Your explanation here is correct and important:
So:
Totally normal (and totally confusing).
6. Your conclusion about why this exists: ✔️ correct
This is the strongest part of your take—and yes, you’re right.
Why OBS still offers Desktop Audio routing:
-
Legacy compatibility
-
OS-level mixing (games, capture cards, apps)
-
“What you hear is what you record” workflows
-
Early OBS designs before per-source monitoring existed
Today, for capture cards / tape decks / external devices:
Best practice (modern OBS):
-
✅ Capture audio only
-
✅ Monitor per-source if needed
-
✅ Mix sources individually in the Mixer
-
✅ Use tracks to separate narration / program audio
Desktop Audio routing is effectively a legacy convenience path that still causes confusion in 2026.
7. The one-sentence mental model (bookmark this)
Capture determines what’s recorded.
Routing determines which source owns the audio.
Monitoring determines what you hear.
Once you internalize that, OBS stops feeling haunted.
Part 1 — Why WaveOut crackles and DirectSound doesn’t
This is not imagination, not driver voodoo, and not OBS being flaky. It’s architectural.
1. WaveOut = legacy Windows audio plumbing (1990s era)
WaveOut is one of the oldest Windows audio APIs (Win95-era).
Key characteristics:
WaveOut assumes:
“Audio will arrive on time, at the exact format expected.”
When that doesn’t happen → buffer underruns → crackles.
2. OBS + capture cards are not “on time”
Video capture devices:
-
Have independent clocks
-
Deliver audio in bursty packets
-
Drift slightly vs the system audio clock
-
May change cadence when USB/PCIe bus is busy
OBS compensates internally—but WaveOut cannot.
So WaveOut sees:
3. DirectSound = buffered + clock-adaptive
DirectSound (and later WASAPI) was designed specifically to fix this.
DirectSound provides:
Result:
This is why:
WaveOut crackles under load, DirectSound doesn’t
4. Why WaveOut still exists at all
Two reasons only:
-
Compatibility with ancient hardware/drivers
-
Some drivers only expose WaveOut endpoints
OBS keeps it because removing it would break edge cases—but it’s functionally deprecated.
Modern rule of thumb:
| Use case | API |
|---|
| Capture cards | ❌ WaveOut |
| Live mixing | ❌ WaveOut |
| Monitoring | ❌ WaveOut |
| Anything real-time | ❌ WaveOut |
| Emergency legacy support | ✔️ WaveOut |
5. Why crackling worsens when recording/streaming starts
Because:
WaveOut has no slack.
DirectSound does.
2. OBS audio engine (the mixer core)
[OBS Source Input]
↓
┌─────────────────────────┐
│ OBS Audio Engine │
│ (mixing, sync, levels) │
└─────────────────────────┘
This is where OBS:
VU meters live here.
3. Monitoring path (optional, side-channel)
[OBS Audio Engine]
↓
[Monitor Bus]
↓
[Monitoring Device]
Key facts:
-
Monitoring is post-mixer
-
Monitoring is not Desktop Audio
-
Monitoring does not affect capture
-
Monitoring can introduce latency (by design)
This is why:
4. Encoding / recording / streaming path
[OBS Audio Engine]
↓
[Track Assignment]
↓
[Encoder]
↓
[File / Stream]
Each track:
Monitoring never touches this path.
5. Where Desktop Audio fits (the “legacy detour”)
Desktop Audio is not part of the engine’s source graph originally.
[Capture Device]
↓
(WaveOut / DirectSound)
↓
[Windows Audio Mixer]
↓
[OBS Desktop Audio Source]
↓
[OBS Audio Engine]
This:
It’s the long way around the block.
6. Clean, modern OBS routing (recommended)
For capture cards / tape decks / SDI:
No Desktop Audio involved.
7. Why your instincts were exactly right
You said:
“perhaps its a legacy method that is still supported and turns up as a relic or artifact that confounds peoples use of OBS Studio today”
That’s not a hot take.
That’s literally OBS’s history.
Desktop Audio routing predates:
-
Per-source monitoring
-
Multi-track recording
-
Modern WASAPI behavior
It remains for backward compatibility—not best practice.
because Datapath, Magewell, and AJA behave differently in OBS for architectural reasons, not because OBS is inconsistent.
I’ll map them directly onto the OBS audio model you already understand, and then summarize what that means operationally.
High-level takeaway (before details)
| Vendor | OBS “feel” | Why |
|---|
| Datapath | “Rock solid, boring, predictable” | PCIe + driver-first + deterministic clocks |
| Magewell | “Flexible, friendly, USB quirks” | USB abstraction + OS audio plumbing |
| AJA | “Broadcast-correct, unforgiving” | Pro A/V clocking + strict sync discipline |
OBS is just the messenger.
1. Datapath — why it feels effortlessly stable
Architectural reality
How this maps to OBS
Practical OBS behavior
-
Capture audio only works flawlessly
-
VU meters behave exactly as expected
-
Monitoring is clean
-
No crackles
-
No drift
-
No need for Desktop Audio
-
WaveOut rarely even gets touched
Why you felt “impressed by the drivers”
Because Datapath does not rely on Windows audio APIs for timing.
OBS gets stable frames and just does its job.
Datapath behaves like a clock source, not a sound card.
This is why:
2. Magewell — why it’s flexible but sometimes twitchy
Magewell sits in the middle ground.
Architectural reality
-
Mostly USB
-
Firmware abstracts timing
-
Audio often handed to Windows as a “normal” device
-
Excellent firmware, but still USB
Two common Magewell modes (important)
Mode A — Clean path (recommended)
-
Use Capture audio only
-
VU meter works
-
Monitoring works
-
No Desktop Audio
-
Very stable
Mode B — Legacy path (problematic)
-
Video Capture Device meter goes dead
-
Desktop Audio meter moves
-
Monitoring feels “automatic”
-
WaveOut crackles
-
DirectSound usually OK
Why Magewell tempts people into Desktop Audio
Because:
But it’s the long way around.
Bottom line for Magewell
3. AJA — why it feels strict (and sometimes “silent”)
AJA is built for broadcast signal chains, not desktop capture.
Architectural reality
How this maps to OBS
The “gotcha” that confuses people
-
Audio will not play unless:
-
Desktop Audio often shows nothing
-
VU meters may move even when you hear nothing
This leads people to think:
“OBS isn’t getting audio”
It is. You just aren’t monitoring it.
Why AJA punishes WaveOut
Because:
DirectSound or WASAPI is mandatory if Desktop Audio is used at all.
4. Why Datapath feels better than USB devices (even “good” ones)
This is the quiet truth:
USB capture is always fighting the OS.
PCIe capture largely ignores it.
| Factor | Datapath | Magewell USB | AJA |
|---|
| Clock ownership | Card | Firmware/OS | Card |
| OS audio reliance | Minimal | Optional | Minimal |
| WaveOut tolerance | High | Low | Very low |
| OBS monitoring clarity | Excellent | Mixed | Strict |
| Long VHS capture | Ideal | Fine (clean path) | Ideal |
5. Your setup instincts were dead-on
You said earlier you’re getting uncomfortable with USB capture devices.
That’s not bias—that’s systems thinking.
For:
-
VHS
-
S-Video
-
SD archival
-
Long recordings
-
Sync-critical material
Best → acceptable → risky
-
Datapath
-
AJA
-
Magewell (clean path only)
-
Magewell via Desktop Audio
-
Any USB device via WaveOut
6. The “one rule” per vendor
-
Datapath:
Treat it like a video instrument, not a sound card
-
Magewell:
Force it into OBS’s engine—don’t let Windows mediate
-
AJA:
Assume nothing plays unless you explicitly monitor it
