Why you cannot hear the remote computer

Screen sharing and audio sharing are unrelated problems that happen to be bundled in some products. Silence in a remote session is usually not a broken setting — it is a feature that was never in the stream.

Capturing system audio is genuinely hard

Capturing a microphone is easy and every platform exposes it. Capturing what the computer is playing is a different problem: you have to tap the output mix, which is a privileged operation and historically not exposed at all.

• Windows has WASAPI loopback, which makes this possible cleanly. This is why system audio capture is most common on Windows.
• macOS has no supported public API for capturing system output. Tools that do it install a virtual audio device — a kernel-level driver — which is why they need extra permissions and break on OS upgrades.
• Linux can do it through PulseAudio or PipeWire monitor sources, reliably enough, but the details vary by distribution.

The consequence for you: audio support is uneven not because developers forgot, but because the capability differs per platform. A tool that carries audio on Windows may genuinely not be able to on macOS.

The browser layer adds two more obstacles

Autoplay policy. Browsers block audio that starts without user interaction. A remote session that connects and begins playing sound may be silently muted until you click something in the page. If a tool has audio and you hear nothing, clicking inside the viewer is worth trying before anything else.

Screen capture with audio. The browser API that captures a screen can request audio too, but support is partial: it generally works when sharing a browser tab, and frequently does not when sharing an entire screen — and it varies by browser and platform. A browser-based remote tool inherits all of those limits.

What tools typically do

When you actually need the sound

1. Ask whether you need it live. Checking that audio plays at all is different from listening to it. Often the real question is "did the meeting recording capture sound", which a waveform or a level meter answers visually.
2. Use a tool with explicit audio redirection if it is a recurring need. RDP inside a VPN is the mature answer here.
3. Join the call directly from your own device. If the remote machine is in a meeting, connecting yourself is better in every way than listening to a re-encoded stream with an extra half-second of delay.
4. Route the audio out separately. A voice call, or a streaming tool on the host, in parallel with the remote session. Ugly, and it works.
5. Do the audio work locally. Anything where you are judging quality, timing or sync should not go through two encoders and a network — the thing you are evaluating is exactly what the transport degrades.

If your tool has audio and it is silent

1. Click inside the session window — autoplay policy is the most common cause in a browser.
2. Check the host's own volume and output device. A host whose output is set to a disconnected HDMI monitor is playing to nothing, and this is invisible from the remote side.
3. Check the viewer's volume and that the tab is not muted; browsers mute tabs per site and remember it.
4. Confirm the host is actually playing something — a silent video file looks identical to a broken audio channel.

More guides