A reliable Teams audio route
Use two separate audio mixes: one for what ForgeBot hears, one for what ForgeBot says.

Research combines official vendor documentation, the live AREA51 tests, Streamlabs logs, the supplied second opinion, and the ForgeBulletin reply. A working test tone is not a working conversation.
External evidence
Does Streamlabs already solve this?
Partly. Streamlabs has Application Audio Capture, per-source monitoring and a selectable monitoring device. Those are the features already used in our attempted route. Its official splitting guide describes built-in app capture and a virtual-cable alternative. This does not establish a built-in virtual microphone that another app can record.
The virtual-camera guide describes sending scenes as video. It is not documentation for an audio input device. I found no publisher-documented Streamlabs Desktop plugin that provides our complete two-way audio connection.
Exeldro’s Audio Monitor is a real OBS Studio plugin: it routes individual sources to audio devices and supports multiple monitoring destinations. Its documented host is OBS Studio. Do not assume it installs in Streamlabs Desktop. The Streamlabs Plugin for OBS runs in the opposite direction: it adds Streamlabs features to OBS Studio.
Higher-level options
| Option | What it provides | Fit here |
|---|---|---|
| Existing VB-Cable | One audio connection. Our alternate playback input passed a recorded tone test. | Fastest next test; already installed. Still needs a separate, verified outgoing route. |
| Wave Link 3 | App/device inputs, up to five mixes, virtual channels and selectable monitor outputs; free on Windows and Mac, with non-Elgato hardware supported. | Strong candidate for a visible two-mix setup, plus Stream Deck integration. Requires its audio driver; not tested on this machine. Vendor guide |
| Logitech MIXLINE | Draw connections from app/device inputs to hardware and one or both virtual outputs. | Closest visual match to our two-direction problem. App capture behavior with this Teams version still needs testing. Vendor setup |
| Voicemeeter Banana | Separate virtual inputs and B1/B2 virtual output buses; published conferencing setup. | Explicit, flexible two-bus routing, but a denser interface. Vendor installation instructions require a reboot, so not an immediate fit for this no-reboot session. Conference guide |
| SteelSeries Sonar | Independent app channels and a streaming mix. | Useful for stream mixing. Verify independent return-feed requirements before choosing it over a two-output mixer. Vendor overview |
| OBS Studio + Audio Monitor | Per-source, per-device monitoring in a supported plugin host. | Good if OBS scenes are wanted too. Still needs an audio device other apps can use as their microphone. More components than a dedicated mixer. |
Why the outgoing route matters
Microsoft explicitly requires Teams and Windows to use the same speaker for shared computer sound on Windows. That explains why “change only Teams’ speaker to the cable and preserve computer-audio sharing” is not a safe assumption. The route must be retested both ways.
For a durable setup, use Teams’ microphone for ForgeBot’s outgoing voice, rather than relying on whole-computer sound sharing. Screen sharing can continue independently. This is an architecture recommendation, not an implemented result.
Proposed two-mix wiring
Do not route Mix 1 back to Teams’ microphone. Do not route Mix 2 into ForgeBot’s microphone. Add monitoring to headphones only where wanted. Exclude the room microphone from the acceptance test.
What the documentation does not prove
- OBS warns that some applications are incompatible with per-app audio capture and recommends direct virtual-cable output as a fallback. That supports testing a direct route, but does not prove this Teams process is incompatible.
- OpenAI’s Voice guide explains microphone access and live conversation, but does not establish the microphone selector available in this exact desktop build. Absence from that guide does not prove absence from the app.
- A sound meter without a reply does not prove echo cancellation. Wrong device selection, a stopped voice session, turn detection and other causes remain possible.
- The VB-Cable manual says the speaker input and 16-channel line input cannot be used at the same time. They are alternative inputs to one cable, not two separate cables.
Internal evidence
Verified
- Teams receives the remote loop and shows the participant as active speaker.
- Windows test tone → CABLE In 16 Ch → CABLE Output recorded successfully: peak −6.5 dB, mean −43.3 dB.
- The stereo cable input is disabled; the alternate 16-channel input is enabled.
- Streamlabs is configured to monitor to the alternate input. Its earlier 0x8889000A monitoring error is absent from the new startup log checked.
Still failing or unverified
- The later ready-state Teams → Streamlabs → cable capture remained silent: mean −91 dB, peak −90.3 dB.
- No fresh remote speech has yet produced a verified live assistant answer.
- The voice app’s active input binding remains unverified.
- Two duplicate cable driver instances show Code 10; Windows refuses the attempted targeted restart because a reboot is pending. No reboot performed.
Private diagnostic audio is stored in ForgeMedia. The successful tone test is asset 438ddc3d-55d9-4d6e-9eed-59c330fe94cc. These test results are local observations, not claims from vendor documentation.
Assessment of the supplied second opinion
The strongest recommendation is to test direct Teams output into the proven cable input, eliminating Streamlabs’ app capture. Its saved per-app microphone finding is also worth checking while Voice is actually running.
The page still contains stale “no cable installed” and “install VB-Cable” text. Its claim that the voice app has no microphone picker is not proved by an omission in documentation. Its final statement that hearing without answering establishes echo cancellation is too strong. The direct-cable suggestion also needs the Microsoft shared-computer-sound constraint above.
The first bulletin reply independently recommended testing both playback inputs before involving Teams or Streamlabs. That test has now succeeded on the alternate input. Removing duplicate driver entries is not required to claim that narrow success and has not been done.
Next test, then the finish line
- While preserving the existing configuration for rollback, send Teams’ speaker directly to CABLE In 16 Ch. Record CABLE Output while the remote loop runs. If speech is absent, stop adjusting the assistant and fix this boundary first.
- If speech is present, select the cable as the actual voice-session input and restart only that session if necessary. Verify an unexpected spoken prompt, not an answer inferred from this report.
- Retest outgoing audio. If shared-computer sound no longer works, use a second independent virtual mix for ForgeBot’s speech → Teams microphone.
- If a mixer is needed, pilot Wave Link 3 or MIXLINE; keep Voicemeeter Banana as the explicit two-bus alternative. Do not install several audio drivers at once.