Browser Meeting Audio Privacy for Mac and Linux in 2026

Browser meeting audio can fail in a way that looks almost convincing. The share preview keeps moving, and the meeting assistant says it's listening. Forty minutes later, the transcript is empty because the browser never received a usable audio track.

That exact failure came up in an Indie Hackers discussion about a bot-free meeting assistant. Users said Chrome on Mac showed the shared window correctly, but the call audio was silent. Linux creates a similar support problem because the result can vary by browser, desktop session, audio server, and source selected in the share picker.

Don't blame the model first. Test the audio stream before testing transcription.

Why screen sharing can look right but have no sound

Browser meeting tools usually use getDisplayMedia() to capture a tab, window, or screen. A page can request audio, but that request is only a preference. MDN warns that the returned stream may have no audio track, even when the app requests one.

That's a privacy feature, not a random omission. A web page can't quietly record every sound on your computer. You choose the source in the browser picker, and the browser decides which audio sources are available on that operating system.

The confusing part is that video and audio can fail separately. A moving preview only shows that the video track works. It doesn't tell you whether the meeting sound works.

Tab, window, and system audio are different

A browser tab is the simplest case. In Chromium browsers, you can usually share the sound from a selected tab by choosing the tab and turning on the audio option. This works well when the meeting runs in that tab.

An application window works differently. If Zoom or Teams is running as a desktop app, selecting its window may share the video without the audio. On macOS, browsers often can't capture audio from another app without a virtual audio device or a native capture path. Sharing a Chrome tab won't capture a call running in the Zoom desktop app.

Linux needs testing on the exact device. PipeWire has improved screen and audio sharing, but browser support and portal settings still vary. Firefox and Chromium don't always offer the same options. A setup that works in one desktop environment may produce a silent stream in another.

Run a 10-second audio check before the meeting

A meeting assistant should show an input meter before saying it has started recording. If you're testing one, check the stream directly:

```js const stream = await navigator.mediaDevices.getDisplayMedia({ video: true, audio: true });

console.log(stream.getAudioTracks().length); ```

A result of zero means the browser returned only video. Don't start transcription. Stop sharing, choose a different source, and try again.

A single audio track is better, but it doesn't prove useful sound is coming through. Play ten seconds of speech and watch the live level meter. It should move as the other person talks. Then record a short sample and play it back. This can catch silent tracks, the wrong input, and microphone-only fallbacks before they ruin a real call.

Mac Fixes

If the meeting runs in Chrome or Edge, keep it there and share that exact tab with tab audio enabled. Don't choose the whole window just because its preview looks cleaner.

If the meeting runs in the Zoom or Teams desktop app, a browser-only assistant might not receive the meeting audio. Your options are a native desktop capture component, a virtual audio device such as BlackHole or Loopback, or a meeting tool that joins the call. Each option has different privacy and setup tradeoffs. The app should explain what it's doing instead of quietly switching to the microphone.

Check macOS permissions too. Screen Recording controls screen capture, while Microphone controls mic input. Granting one doesn't grant the other. After changing either permission, restart the browser before testing again.

Linux Fixes

Use a current Chromium browser with a meeting open in a browser tab. Select the tab, enable audio if the picker offers it, and check the input meter. This removes several variables at once.

If you need audio from a desktop app, check whether the session uses PipeWire and whether the desktop portal is working correctly. Try a second browser too. If the picker never offers audio, don't assume a JavaScript flag can force it. The browser may ignore the request because that source isn't available in the current environment.

Record the exact setup that works: the Linux distribution, desktop environment, Wayland or X11, browser version, meeting app, and selected share source. "Works on Linux" is too vague to help the next person troubleshoot it.

Privacy questions to ask

A meeting assistant without a bot may feel less intrusive because no visible participant joins the call. That doesn't make it private. Your browser still captures the audio, and the service may send the audio or transcript to a server.

Before using one, check what it captures, whether it stores audio, where transcription happens, how long transcripts are kept, and how deletion works. Tell everyone in the meeting when the call is being transcribed. Hidden recording should not mean hidden consent.

Local processing sends less meeting audio elsewhere, but it doesn't solve source selection. A local model can't transcribe audio the browser never captured.

Where DictaFlow fits

DictaFlow is a voice typing tool, not a meeting recorder. Hold a shortcut to let it listen to your microphone, and it places editable text at your cursor. It doesn't capture browser system audio on Linux, and it doesn't currently offer a Linux app.

It handles meeting-related text work on Windows, Mac, iPhone, iPad, and Android. You can dictate an email follow-up, turn rough notes into a clear message, or enter text in apps without built-in voice features. The DictaFlow's dictation software comparison explains how it differs from Otter, meeting bots, and built-in voice typing.

The difference matters. Meeting transcription records other people, so it needs a reliable shared audio path. Dictation records you, so it needs reliable microphone input and text insertion. Test the path that matches the job.

If writing follow-ups is the problem, not recording calls, try DictaFlow free on a supported device and test it in the apps you already use.

The short version

Never trust a moving screen preview to confirm audio. Check that the stream has an audio track, watch the live meter, and record a ten-second sample before the meeting starts.

On Mac, sharing the meeting's browser tab is usually easier than capturing a desktop app. On Linux, test the exact browser, desktop session, and source. If you don't see the audio option, fix the capture path before changing the transcription model.