How to Fix Audio and Video Sync in OBS

The clap lands, the mouth moves, and the sound arrives a beat late in the recording. On your monitor it looked fine. That gap between what you saw and what got saved is the whole problem in one sentence.

Sync issues in OBS come in three flavors, and they need three different responses:

• A fixed offset — the gap is the same at minute one and minute thirty. This is correctable with a source-level sync offset.
• A growing drift — the gap widens as the session runs. No offset will hold, because the target keeps moving.
• A path problem — a sample-rate mismatch, a driver issue, or a capture device mishandling audio. The offset slider is the wrong tool entirely.

Your first job is not to move a slider. It is to find out which of the three you have. Most wasted troubleshooting time comes from applying an offset to a drift, or chasing a driver problem with a timing fix.

Before You Touch Any Slider

Diagnosis only works if the test is repeatable. Get the environment stable first.

Decide what you are judging against. The OBS preview, a local recording file, and the live stream can each show a different result. The preview passes through your monitoring path, the recording is what OBS actually wrote, and the stream has been through platform ingest and playback on top of that. Judge against the local recording. It is the only one you control end to end.

Note the state of everything that can change the answer. OBS version, capture-device driver and firmware, audio-interface driver, operating system, and whether monitoring is enabled. Write these down. If a fix works today and fails after an update, you want to know what changed.

Bypass anything that adds its own delay. Noise suppression, other audio filters, virtual audio cables, Bluetooth audio, and platform-side processing all sit in the path and can contribute their own timing. Turn them off for the test. Add them back one at a time afterward if you need them.

Record locally, not to the stream. Platform ingest and playback add timing you cannot measure or control. A local recording removes that variable.

One assumption to state plainly: this procedure diagnoses and corrects timing. It will not fix a device that is dropping audio or resampling it badly. Those are different failures with different symptoms, and they show up later in this article.

Which Direction Is the Mismatch?

Direction determines which source gets the offset, and getting it backwards doubles your error. Measure it instead of eyeballing it.

Create a single shared event. Clap your hands once, or use a flash paired with a sound, recorded into the same take. Audio and video now share one moment you can point to. A clap is usually enough; a flash plus sound is easier to spot when the gap is small.

Step through the recording frame by frame. Find the frame where the clap happens visually and the frame where the sound spike appears on the audio waveform. Count the frames between them.

Convert frames to milliseconds. Divide the frame count by the recording frame rate, then multiply by 1000. At 30 fps, a 3-frame gap is 100 ms. At 60 fps, the same 3 frames is 50 ms. The frame rate matters, so use the one the recording was actually written at.

Get the direction right. If audio arrives late — you hear the clap after you see it — the audio source needs a negative offset. If audio arrives early, it needs a positive offset. The rule is consistent: you are shifting the audio's position on the timeline, so a late sound moves earlier and an early sound moves later.

Measure twice. Take a reading at the start of the recording and another after several minutes of continuous capture. Same number both times means a fixed offset. A different number means drift, and you should stop here and read the next section before changing anything.

Write the number down before you change anything. Without a baseline, you cannot tell whether your correction worked or just moved the problem.

Fixed Offset vs. Growing Drift

This is the decision boundary that saves the most time, so treat it as a hard fork rather than a detail.

A fixed offset stays constant. The gap at minute one matches the gap at minute thirty. This is what a source-level sync offset is designed to correct, and it is the common case when a microphone or interface enters OBS on a separate path from the camera.

Drift grows over time. It points to a clock, sample-rate, or buffering mismatch between two devices rather than a constant delay. Common causes:

• A camera and an audio interface running on independent clocks that tick at slightly different rates.
• A capture device resampling audio on the way in.
• A device whose sample rate does not match the rate OBS is running at.

The trap is test length. A mismatch that looks perfectly fixed in a 30-second test can reveal itself as drift across a 30-minute session. If you only ever test with a quick clap, you will "fix" a drift with an offset, ship it, and watch it come apart by the end of a long stream.

So test at the length you actually work at. If your sessions run an hour, your sync test should run long enough to expose a slow divergence — several minutes minimum, ideally matching a realistic session.

If the gap changes, stop adjusting offsets. An offset that is correct at minute one will be wrong by minute thirty, and you will have added a second problem on top of the first.

Apply the Offset to the Right Source

Once you have confirmed a fixed offset and measured its direction and size, the correction itself is small — but the sign and the source have to match, or you make the problem worse.

Find the per-source setting. Sync offset lives in the source's advanced audio properties, not in a global setting. Open the audio mixer, open advanced audio properties, and find the row for the specific source that is out of time. Each source carries its own offset value.

Work through one concrete example. Your camera video is the reference. Your microphone audio arrives 100 ms late — you hear the clap after you see it. The microphone is the source that is out of position, so you apply the offset to the microphone, and because the audio is late, you enter a negative value of roughly -100 ms. The video source stays at zero. Re-record and confirm the clap lines up.

Now the opposite case, in one line. If the microphone audio arrives 100 ms early, you still apply the offset to the microphone, but you enter a positive value of roughly +100 ms. The source that owns the problem is the one you measured as out of position; the sign follows the direction you measured. Applying the offset to the wrong source doubles the error instead of removing it.

Understand what the offset does. It shifts when that source's audio is presented relative to the video timeline. That is exactly what a constant delay needs, and exactly what it cannot fix if the delay is changing.

Re-record and re-measure. Do not assume the first value is correct. Run the same clap test, step through the new recording, and confirm the gap is gone. If it is smaller but not gone, adjust by the remaining amount rather than starting over.

Verify against the file, not the monitor. Monitoring and the recorded file can behave differently, especially when monitoring routes through a different device or adds its own latency. The recording is what your audience sees. Check that one.

When the Offset Does Not Hold

If the gap returns, changes, or never quite settles, you are past the offset and into the signal path. The fastest way through is to match what you observe to the next test, rather than working the whole chain in order.

What you observe	Likely layer	Next test	What moves you forward
Gap is constant at start and end	Fixed offset	Apply source offset, re-record	Gap gone → keep the value
Gap grows across the session	Clock or sample-rate mismatch	Compare sample rates across OBS, OS, interface, capture device	Rates differ → align and repeat the start/end test
Audio missing, doubled, or echoing	Monitoring or routing	Check monitoring output and source duplication	Duplication found → fix routing, not timing
Mismatch only in preview, not in the file	Monitoring path	Compare preview against local recording	File is clean → monitoring latency, not a sync fault
Mismatch only in the recording, not in preview	Capture or encode path	Re-test with filters and virtual cables removed	Gap persists → capture device or driver

Check sample rate consistency first. OBS, the operating system audio settings, the capture device, and the audio interface all have a sample rate. If they disagree — say, one device at 44.1 kHz and the rest at 48 kHz — something in the chain is resampling, and resampling introduces timing behavior an offset cannot track. Treat this as a high-priority hypothesis, not a settled verdict: align every device to the same rate, then repeat the same start-and-end measurement. If the drift disappears, the mismatch was the cause. If it does not, move on to driver, firmware, buffering, or device-specific behavior rather than assuming the rate was the whole story.

Trace where the audio actually comes from. If audio is embedded in the capture signal — arriving over HDMI with the video, for example — the capture device's handling of that audio is part of the path and can introduce its own delay. If audio arrives through a separate interface, the interface driver and its buffer settings sit between the microphone and OBS. These are different paths with different failure modes, and knowing which one you have narrows the fix.

Separate capture from passthrough. What you see on your monitor and what OBS records are different paths. A capture card typically forwards a signal to your display while separately capturing and encoding it for the computer, and those two paths can have different timing. A monitor that looks perfectly in sync does not prove the recording is. This is why the earlier instruction to judge against the file matters — it is the only path your audience experiences.

Distinguish configuration from hardware limits. A sample-rate mismatch is a configuration problem and is fixable. A device that cannot hold a stable clock is a hardware limit, and no setting will rescue it. The test is simple: if aligning sample rates and drivers makes the drift disappear, it was configuration. If drift persists after everything is aligned, the component is the limit.

Reduce the Chance It Comes Back

A one-time fix that you have to redo before every session is not really fixed. Make the corrected state the default.

Lock the sample rate across every device in the chain and keep it consistent between sessions. Pick one rate — 48 kHz is a common working choice for video — and set it everywhere: OBS, the operating system, the interface, the capture device.

Keep device order and port assignments stable. Moving a capture device or interface to a different port or hub can change how it enumerates and behaves. If a configuration works, leave the cables where they are.

Save the corrected configuration. Store your scenes and sources as a scene collection, and your settings as a profile, so the offset travels with the setup instead of living in your memory.

Re-verify after any update. Driver, firmware, and OBS updates can change audio handling and defaults. OBS release notes have, in past versions, included changes to how audio monitoring and duplication behave, which is exactly the kind of thing that can shift your timing. After an update, run the clap test again before you go live.

Keep a short personal checklist. Reference test, measure, confirm against a recording, then go live. Four steps, a few minutes, and it catches most of this before an audience does.

When to Stop Adjusting and Change the Setup

At some point the question stops being "what setting fixes this" and becomes "is this component the limit." Here is the decision rule.

Keep your current setup if a single measured offset holds across a full-length session. That is a solved problem. Do not replace hardware that is working.

Reconfigure if the mismatch tracks a sample-rate or driver setting you can align. This is the largest and cheapest category of fixes, and it covers most drift.

Replace a component only when drift persists after clock and sample-rate alignment, or when a capture device cannot pass audio reliably in the format you need. That is the point where the hardware, not the configuration, is the constraint.

If you are choosing a capture path and audio reliability matters to you, weight documented audio handling and format support above headline resolution. A card that advertises high-resolution capture but mishandles audio still breaks your stream, and the resolution number will not save you. Official spec sheets are useful for confirming what formats and connections a device supports; they are not evidence that its audio timing will be better than a competing card's.

One honest limit on the evidence: comparable, controlled audio-video latency measurements across capture devices are not widely published. Vendor latency claims are claims, not guarantees, and they are usually measured under conditions that may not match yours. Treat them as a starting point for your own testing, not a substitute for it.

The Habit That Prevents Most of This

Sync problems are not mysterious once you separate the three causes. A fixed offset is a number you measure and correct. A drift is a clock or sample-rate mismatch you align. A path problem is a component or configuration limit you either fix or replace.

The decision rule is short. If one measured offset holds for a full session, you are done. If the gap grows, stop adjusting and fix the clock or sample-rate path. If it still drifts after that, the component is the limit, and no slider will save it.

The habit that keeps you out of this entirely: measure with a reference, verify against a recording rather than your monitor, and re-check after any update. A clap and two minutes of frame-stepping before a session costs far less than discovering the problem in a finished recording.