Screen-Share Audio Drifting Out of Sync With Your Whiteboard? Here's Why Zoom and Meet Do This

Why Screen-Share Audio Drifts When Regular Video Calls Don't

On a standard webcam-only video call, your microphone audio and camera video are both captured as a single relatively tightly-coupled stream by the conferencing app — the software has one job, syncing one video source to one audio source, and it's been optimized for exactly that for years. The moment you start screen sharing, the app is now juggling a second video feed (your desktop, a whiteboard app, or a slide deck) that's captured through a completely different subsystem — a screen-capture API rather than a camera driver — and that stream has its own frame timing that isn't natively locked to your microphone's audio clock the way camera video usually is.

During a live call, small timing differences between these pipelines are usually invisible because both participants' brains fill in minor gaps and the call software is actively compensating in real time. The problem shows up specifically in recordings because a recorded file has to commit to one fixed timeline, and once you start actually reviewing the footage — which is exactly what a student rewatching a tutoring session does, often pausing and scrubbing — a drift that was imperceptible live becomes obviously distracting by the second half of the recording.

Two Pipelines, One Recording: How Zoom and Meet Actually Capture Your Session

Zoom and Meet both treat "shared screen content" as a distinct stream from your camera and microphone internally, which is part of why you can toggle screen share on and off mid-call without restarting your audio — they're not the same pipe. When you record locally or in the cloud, the app (or your third-party recorder) has to mux — combine — these separate streams back into one video file with a single synchronized timeline, and that muxing step is where accumulated drift gets baked in permanently. A live call can tolerate small desync because it self-corrects continuously; a finished recording cannot, because whatever offset existed at the point the recording stopped is now permanent in the file.

This is also why the drift is worse in longer sessions and worse when your system is under more load — a laptop juggling screen capture, webcam encoding, audio processing, and whatever tutoring app or whiteboard software you're also running simultaneously is more likely to have one pipeline briefly stall relative to the other, and those small stalls are cumulative rather than self-correcting once they're written to a file.

The OS-Level Audio Loopback Device Most Drift Problems Trace Back To

If you're recording system audio (the student's voice through your speakers, or app audio from a video you're sharing) alongside your own microphone, you're almost certainly routing through some form of audio loopback device — Windows' Stereo Mix, a virtual audio cable like VB-Cable, or macOS tools like BlackHole or Loopback. These virtual devices capture whatever's playing through your speakers and feed it back into your recording software as if it were a microphone input, and they're a common and legitimate way to record system audio — but they introduce their own buffering layer with its own sample rate setting, separate from your physical microphone's sample rate.

When the loopback device is set to 44.1kHz and your microphone or recording software is set to 48kHz (or any other mismatch), the two audio streams technically play back at very slightly different effective speeds relative to each other, and that tiny discrepancy compounds minute after minute into the audible drift you're noticing. This is usually the single highest-value thing to check first: open your OS sound settings and your recording software's audio settings side by side and confirm every audio device involved — microphone, loopback/virtual cable, and the recording software's own input — is set to the identical sample rate, typically 48kHz for anything destined for video.

Zoom Settings That Prevent Drift

In Zoom, go to Settings > Audio and confirm "Automatically adjust microphone volume" and any automatic gain features aren't fighting with a separately-configured loopback device — leave Zoom's own audio processing on for your mic, but make sure you're not double-processing the same signal through both Zoom and a separate virtual audio mixer. When sharing a screen with system audio (checking "Share sound" or "Share computer sound" in the share dialog), Zoom routes that audio through its own internal pipeline rather than your OS loopback device, which is usually more reliable for sync than a manually configured virtual cable — if you're currently using a separate loopback setup out of habit, switching to Zoom's native "share sound" option for anything played from your own computer often resolves drift immediately.

If you're recording locally rather than to the cloud, Zoom's local recording defaults to a fixed, consistent frame rate and audio sample rate that's generally well-synced on its own; most drift in Zoom recordings specifically comes from third-party recording software layered on top (like OBS capturing a Zoom window) rather than Zoom's built-in recorder. If that's your setup, the fix belongs in the third-party tool's settings, covered next, not in Zoom itself.

Google Meet and Third-Party Recorder Settings to Check

Google Meet's built-in recording (available on Workspace plans) handles muxing server-side in the cloud rather than locally, which generally produces more consistently synced output than a local capture setup — but it also means you have less direct control over buffer settings if drift does occur, and the fix is usually on the presenter's end: closing unnecessary tabs and background apps that compete for CPU during the recording, since Meet's client-side capture quality still depends on your machine keeping up in real time before anything reaches Google's servers.

If you're using a third-party recorder like OBS or Camtasia to capture a Meet or Zoom window locally instead of relying on built-in recording, set a fixed (constant) frame rate rather than a variable one in the recorder's video settings, and explicitly set the audio sample rate to match your loopback device and microphone — most drift issues in this exact setup (recording someone else's tutoring call locally) trace back to the recorder defaulting to a different sample rate than the source audio devices. This is the identical underlying issue covered in more depth in our guide to OBS buffer underruns when recording a remote guest, since both problems come from mismatched audio/video pipelines feeding a local recorder.

Bluetooth Headsets and Other Hardware That Makes Drift Worse

Bluetooth audio adds a variable amount of latency depending on the codec your headset negotiates with your computer, and that latency isn't fixed — it can shift slightly during a session as the connection quality changes, which is a much less stable foundation for a recording than a wired USB headset or a 3.5mm connection. If you're tutoring for extended sessions and recording for later review, a wired mic and headphones remove one entire variable source of drift; see our Bluetooth headphones troubleshooting guide if you need to keep Bluetooth working reliably for shorter calls where the drift is less noticeable.

Beyond Bluetooth specifically, any USB hub, dock, or extension cable between your microphone and your computer can introduce small, inconsistent latency, especially on lower-powered laptops handling screen capture and video encoding simultaneously. If you've already fixed sample rate mismatches and you're still seeing drift, connecting your microphone directly to a native USB port rather than through a hub is worth testing before assuming it's a software configuration issue.

Recordings Drifting Out of Sync and You Need It Fixed Before the Next Session?