punktfunk/docs-site/content/docs/echo.md at 4c587ef53162322e18a438cc33228470b3246742

Files

T

enricobuehler 4a621de6b1 chore(packaging): retire VB-Cable — audio's substrate is Steam's drivers

The other half of the audio-substrate decision (spikes S2+S3 green, minted
endpoints landed in the previous commit): stop bundling a third-party
kernel driver the host no longer needs.

  installer      the VB-CABLE task, payload, silent-install run and the
                 donationware notice are gone; a suppressible notice tells
                 a Steam-less box that audio needs Steam INSTALLED (never
                 running) and that installing it later just works. A cable
                 from an older install is still deliberately not removed.
  packer + CI    -VbCableDir/VBCABLE_DIR, the staged-payload check and the
                 runner provisioning download are gone; SBOM drops the
                 redistributed-driver component.
  winget         the VB-Audio bundling-grant agreement becomes the honest
                 Steam requirement (surfaced on the unattended path where
                 no wizard is on screen).
  docs           windows-host/uninstall/security/echo say what actually
                 ships: no kernel-mode driver of our own, endpoints minted
                 from Valve's vendor-signed drivers, VB-CABLE mentioned
                 only as the historical fallback that keeps working.
  host wording   the mic-open guidance and module headers lead with Steam;
                 the NAME ladder itself is untouched — demoting 'cable
                 input' was considered and rejected (on a box where minting
                 transiently fails, the SSM would outrank an installed
                 cable, steal the silent sink, and make audio host-audible).

2026-08-07 11:27:29 +02:00

3.8 KiB

Raw Blame History

title, description

title	description
Why do I hear myself	Echo while streaming — the four places it can come from (client speakers, Windows monitoring loops, host speakers, virtual mixers) and how to stop each one.

You talk into your device's microphone and hear your own voice come back a beat later. The echo is almost never "in the stream" itself — it's a loop in one of four well-known places. Work through them in order; the first two cover nearly every report.

Your device's speakers

If the stream's audio plays out of the speakers of the device you're streaming on — a phone, tablet or laptop without headphones — its microphone picks that sound back up and sends it to the host along with your voice. Everyone in your voice chat hears the game twice, and you hear yourself whenever anything routes the mic back.

Fix: use headphones on the device you're streaming on. Clients also try to cancel it for you: Echo cancellation in client settings is on by default on Linux, Windows, the console home, the Apple apps and Android, and hands the microphone to the system's own canceller. How much it removes depends on the device — a laptop with a good array mic can clear it entirely, a cheap USB mic next to a speaker can't — so headphones remain the reliable fix everywhere.

If you just need to stop talking for a moment, Ctrl+Alt+Shift+V mutes the microphone without leaving the stream; see Input.

"Listen to this device" and app monitoring (Windows hosts)

Windows can play a microphone straight out of the speakers. If Listen to this device is ticked for the Punktfunk mic — a Steam Streaming Microphone-class device on current hosts, CABLE Output on older ones — your voice plays on the host's output, which the stream then captures and sends right back to you.

Open Sound settings → More sound settings → Recording, double-click the Punktfunk mic, and on the Listen tab untick Listen to this device.

The same loop hides in apps: Discord's Mic Test / input monitoring, OBS's Monitor audio on a mic source, and similar monitoring features in other tools all play your mic into the host's output. Turn the monitoring off rather than the mic.

The host's own speakers

If you set PUNKTFUNK_HOST_AUDIO (Windows) so the stream's sound also plays in the room, and you're streaming from that same room, your device's mic hears the host's speakers. Remove the setting while you stream from nearby, or turn the host's volume down.

Virtual mixers (VoiceMeeter and friends)

VoiceMeeter's virtual devices all share one internal mixer. Older Punktfunk hosts could pick one VoiceMeeter strip as the microphone target and another as the audio capture — a feedback loop with no acoustics involved at all. Current hosts refuse to capture VoiceMeeter or other virtual endpoints for desktop audio, so this fixes itself with an update. If you route audio through VoiceMeeter on purpose, make sure no strip that hears the Punktfunk mic feeds the output being streamed.

What the host log can tell you

While your microphone is in use, the host writes a mic uplink health line to its log every 30 seconds (web console → Logs). It shows how much of your voice is buffered on the host (depth_ms vs target_ms), how much the network lost (gaps, concealed), and how steadily your client is delivering audio (cadence_ms). It won't point at an echo loop directly — echo is a routing problem, not a network one — but if your voice also sounds choppy or delayed, include that line in a bug report. The startup log also names exactly which devices the host picked for the microphone and for audio capture, which is the quickest way to spot a monitoring loop like the ones above.

3.8 KiB Raw Blame History