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:

Audio is being captured
It is visible on the Video Capture Device VU meter
But:
- Audio Monitoring defaults to OFF
- So OBS records it silently (to your ears)

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
- Set the relevant source to:
  - ✅ Monitor and Output
Settings → Audio
- Monitoring Device must be set
  (this is the step many people miss)
  e.g.:
  - Speakers
  - Headphones
  - Interface output
Desktop Audio device
- ❌ Does not need to be enabled unless you’re routing via Desktop Audio
- This is where your description slightly overreaches

Correction 👇

“The Desktop Audio Device must not be disabled”

That is only true if:

You are using Output desktop audio (DirectSound/WaveOut)

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:

VU meters reflect ownership, not “audibility”
If audio is routed:
- Into a source → that source’s meter moves
- Out to Windows → Desktop Audio meter moves
Monitoring does not create a second meter

So:

You can hear audio with no meter moving
Or see meters moving with no sound

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:

High latency
Small, fixed buffers
Minimal timing correction
Poor resampling
No real-time clock recovery

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:

audio arrives late → buffer empty → pop
audio arrives early → buffer overwrite → pop

3. DirectSound = buffered + clock-adaptive

DirectSound (and later WASAPI) was designed specifically to fix this.

DirectSound provides:

Larger ring buffers
Timestamp-aware scheduling
Drift compensation
Software resampling
Mixer-level clock alignment

Result:

OBS can “float” the audio slightly
Minor timing errors are smoothed
No audible crackles

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:

CPU load increases
USB / PCIe bus contention increases
Encoder threads preempt audio threads

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:

Resamples audio
Syncs to video
Applies gain
Routes to tracks
Decides who owns the VU meter

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:

You can hear audio with no meter
Or see meters with no sound

4. Encoding / recording / streaming path

[OBS Audio Engine] ↓ [Track Assignment] ↓ [Encoder] ↓ [File / Stream]

Each track:

Gets a copy of the mixed audio
Or isolated sources (if configured)

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:

Adds latency
Loses source identity
Breaks clean monitoring
Causes crackles if WaveOut is used

It’s the long way around the block.

6. Clean, modern OBS routing (recommended)

For capture cards / tape decks / SDI:

Capture audio only
        ↓
OBS Audio Engine
        ↓
Monitor (if needed)
        ↓
Encoder

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

PCIe capture
Audio and video are:
- Clocked together
- Delivered synchronously
- Timestamped deterministically
No OS audio stack involved unless you force it

How this maps to OBS

Datapath Card
   ↓ (DMA, fixed cadence)
OBS Source Input
   ↓
OBS Audio Engine
   ↓
Encoder / Monitor

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:

VHS capture
SDI ingest
Long recordings
…all “just work.”

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)

Magewell
   ↓ (direct to OBS)
OBS Source Input
   ↓
OBS Audio Engine

Use Capture audio only
VU meter works
Monitoring works
No Desktop Audio
Very stable

Mode B — Legacy path (problematic)

Magewell
   ↓
Windows Audio (DirectSound/WaveOut)
   ↓
OBS Desktop Audio
   ↓
OBS Audio Engine

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:

Windows immediately plays the sound
You hear audio without touching monitoring
It feels intuitive

But it’s the long way around.

Bottom line for Magewell

Magewell is not unstable
But it will happily let you use unstable paths
OBS won’t stop you

3. AJA — why it feels strict (and sometimes “silent”)

AJA is built for broadcast signal chains, not desktop capture.

Architectural reality

PCIe (usually)
Audio is:
- Embedded
- Clock-locked to video
- Meant for SDI/HDMI workflows
Drivers expect downstream devices to respect timing

How this maps to OBS

AJA Card
   ↓ (locked A/V frames)
OBS Source Input
   ↓
OBS Audio Engine
   ↓
Encoder

The “gotcha” that confuses people

Audio will not play unless:
- Monitoring is explicitly enabled
- Monitoring device is set correctly
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:

AJA audio cadence is precise
WaveOut cannot keep up
Buffer underruns happen immediately

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

2/02/2026

OBS Studio - Video Capture routing vs monitoring audio

1. What Audio Output Mode on a Video Capture Device actually does

The three modes:

1) Capture audio only

2) Output desktop audio (DirectSound / WaveOut)

2. Monitoring vs capture (this is the key mental model)

3. Why audio is silent in “Capture audio only”

4. What’s required to hear monitored audio (your checklist is almost perfect)

Required conditions (cleaned up):

Correction 👇

5. VU meters — why they behave “weird”

6. Your conclusion about why this exists: ✔️ correct

Why OBS still offers Desktop Audio routing:

Best practice (modern OBS):

7. The one-sentence mental model (bookmark this)

Part 1 — Why WaveOut crackles and DirectSound doesn’t

1. WaveOut = legacy Windows audio plumbing (1990s era)

2. OBS + capture cards are not “on time”

3. DirectSound = buffered + clock-adaptive

4. Why WaveOut still exists at all

Modern rule of thumb:

5. Why crackling worsens when recording/streaming starts

2. OBS audio engine (the mixer core)

3. Monitoring path (optional, side-channel)

4. Encoding / recording / streaming path

5. Where Desktop Audio fits (the “legacy detour”)

6. Clean, modern OBS routing (recommended)

7. Why your instincts were exactly right

High-level takeaway (before details)

1. Datapath — why it feels effortlessly stable

Architectural reality

How this maps to OBS

Practical OBS behavior

Why you felt “impressed by the drivers”

2. Magewell — why it’s flexible but sometimes twitchy

Architectural reality

Two common Magewell modes (important)

Mode A — Clean path (recommended)

Mode B — Legacy path (problematic)

Why Magewell tempts people into Desktop Audio

Bottom line for Magewell

3. AJA — why it feels strict (and sometimes “silent”)

Architectural reality

How this maps to OBS

The “gotcha” that confuses people

Why AJA punishes WaveOut

4. Why Datapath feels better than USB devices (even “good” ones)

5. Your setup instincts were dead-on

Best → acceptable → risky

6. The “one rule” per vendor