Using Virtual Desktop without Echoing Audio from Primary Display when Using Stream to 3D

This guidance explains how virtual‑audio‑capturer (shipped with Stream to 3D) works and how to wire it up cleanly with Voicemeeter Banana (and, by extension, Virtual Desktop), so you can capture the primary display’s “what‑you‑hear” without echoing the 3D playback.

How virtual‑audio‑capturer actually works (in plain English)

  • What it is: a DirectShow capture filter that exposes a recording     device called “virtual‑audio‑capturer”. Apps like FFmpeg, OBS, GraphStudio, or your own pipeline can open it as if it were a microphone.
        Under the hood it uses WASAPI loopback to read the mixed PCM stream from a render (playback) endpoint — essentially “record whatever is coming out of this output device”.
  • What it captures: by default, the loopback mix of the Windows default playback device (or whichever specific endpoint the filter is coded to open). That means whatever applications are sending audio to the default output are what you’ll capture.
  • Why echo happens: if your player (e.g., MPC‑HC) also plays to that same default device, its audio is mixed back into the loopback stream and then re‑captured by virtual‑audio‑capturer, producing a feedback/echo when you simultaneously monitor the player on another device.

The clean routing model (no echo)

You want two independent audio paths:

  1. Capture path (for conversion):
        Only the apps that produce the source video’s sound (e.g., Chrome/YouTube) → Windows default playback device → virtual‑audio‑capturer     loopback → your capture/convert pipeline.
  2. Playback path (for VR / external display):
        MPC‑HC (or your player) → Voicemeeter virtual input (VAIO/AUX) → A1/A2 output that feeds Virtual Desktop / headset — not the default playback device above.

This separation ensures the loopback capture contains just the source audio, while your 3D playback goes somewhere else.

Step‑by‑step setup (fresh machine order)

  1. Install Voicemeeter Banana (VB‑Audio) (the  free option is fine) and reboot so its drivers register (Voicemeeter Input, Voicemeeter AUX Input, Voicemeeter VAIO/AUX playback endpoints).
        Rationale: you’ll use Voicemeeter’s virtual inputs as targets     for your 3D player (MPC‑HC) and you’ll pick a hardware A‑bus that matches your VR/Virtual Desktop audio device.
  2. Install Screen‑Capture‑Recorder + virtual‑audio‑capturer (the rdp packages). These are installed by the Stream to 3D installer. Reboot if the installer asks.
        Now you should see a DirectShow audio device called virtual‑audio‑capturer.
  3. (Optional) Install Virtual Desktop Streamer (latest). If it offers “Use Voicemeeter”, enable it when you intend to route VR audio via Voicemeeter. (This typically tells VDS to prefer a Voicemeeter output as its input/monitor path.)

Windows sound control — make the split

Pick your “default” playback device — the device whose loopback you want to capture with virtual‑audio‑capturer.

  • For example: set “Speakers (Realtek/Intel)” as Default in Settings → System → Sound → Output.
  • This is where Chrome/YouTube will play by default — i.e., the content you’re capturing.

Use per‑app output routing so that MPC‑HC (your 3D playback) does not     go to the default device:

  • Settings → System → Sound → Volume mixer (Windows 11), or App volume and device preferences (Windows 10).
  • For MPC‑HC, set Output device = Voicemeeter Input (e.g., Voicemeeter Input (VB‑Audio Voicemeeter VAIO) or Voicemeeter AUX Input).
  • For Chrome, leave it on Default (your speakers).
         Result: Chrome → Speakers (default) → captured by virtual‑audio‑capturer. MPC‑HC → Voicemeeter only, therefore not re‑captured.

(Windows’ loopback behaviour is documented by Microsoft: loopback captures the mix for the chosen render endpoint; per‑app routing lets you decide which apps go to which endpoints. Microsoft Learn)

Voicemeeter Banana — simple, robust busing

Open Voicemeeter Banana and set the right outputs:

  • A1      = your VR/Virtual Desktop audio sink (e.g., your headset USB DAC / Virtual Desktop’s chosen Windows output device).
  • A2      (optional) = your PC speakers if you want to also hear the 3D playback locally.

On the virtual input strip you picked for MPC‑HC (VAIO or AUX):

  • Light A1 (to send to the headset) and optionally A2 if you also want local monitoring.
  • Leave B1/B2 off unless you intentionally need to pass that bus into another app; keeping them off reduces chances of re‑injection.

Now MPC‑HC’s audio lives inside Voicemeeter and goes to the VR output(s) you’ve selected — completely isolated from the default speaker device that virtual‑audio‑capturer is loopbacking.

MPC‑HC specifics (two options)

Option A — use Windows per‑app routing (recommended):
Leave MPC‑HC’s own audio renderer as “System Default”, then in the Windows Volume Mixer set the output device for mpc‑hc.exe to Voicemeeter Input. Easy to maintain; survives player reinstalls.

Option B — force in‑player device:
In MPC‑HC → Options → Playback → Output → Audio Renderer, choose Voicemeeter Input (VAIO or AUX). This pins MPC‑HC to Voicemeeter regardless of Windows routing.

Either way, the result must be MPC‑HC → Voicemeeter, Chrome → Default Speakers.

With the newer VD Streamer builds, Use Voicemeeter generally means: VDS prefers feeding/monitoring from a Voicemeeter path so the headset hears whatever you bus to Voicemeeter’s A1. That aligns nicely with the model above — you’re already sending MPC‑HC → Voicemeeter → A1 (headset). Keep Chrome on Default Speakers so it’s not heard in the headset (unless you explicitly route it into Voicemeeter too).

Troubleshooting & gotchas

  • No sound anywhere: after installing audio drivers (Voicemeeter/rdp), reboot. Windows sometimes needs a logoff/reboot to expose new endpoints to apps.
  • Echo persists: verify Windows Volume Mixer shows MPC‑HC on Voicemeeter Input and Chrome on Default; also check Voicemeeter that the virtual input strip isn’t sent to a device that is also your default speakers (or, if it is, turn your speakers down/mute them so the loopback doesn’t include room pickup via microphones etc).
  • Capture is silent while Chrome plays: confirm Default output really is your speakers (and not the headset or Voicemeeter). Loopback only grabs the endpoint you configured. Microsoft’s loopback doc is explicit about capturing a specific render endpoint. Microsoft Learn
  • Want to capture a non‑default output’s loopback?
        virtual‑audio‑capturer typically targets the default; if you need a different endpoint’s loopback you’d either (a) make that endpoint default while capturing, (b) use a tool that lets you select loopback of a chosen device, or (c) customise a WASAPI loopback capture to open a specific IMMDevice     (see the MS sample posts for how). Matthew van Eerde's web log

Why this works

  • virtual‑audio‑capturer is a loopback reader — it gets exactly the mixed PCM that’s being rendered     to an endpoint. Keeping the player’s audio on a different endpoint     (Voicemeeter) means there’s nothing to echo into the captured stream. GitHubMicrosoft Learn
  • Voicemeeter gives you flexible routing so you can feed the headset/Virtual Desktop only the 3D playback, while the browser/source audio stays on the default speakers (for capture).

Click here to go to the Usage and Configuration home page.