OBS Audio Out of Sync: Measure Delay Before Changing Settings

Original synthetic demonstration

Practise measuring a known offset

Turn playback volume down first. Flash warning: each video has one small white flash every two seconds. Synthetic tone bursts; no OBS recording. Download for timeline measurement; not a device-calibration test.

Download the files, import them into an editor that shows video frames and audio waveforms, and compare the event positions on its timeline. These files illustrate a known offset; they do not calibrate your camera, microphone or playback chain.

Unencoded audio and caption-text downloads

The WAV files contain the tone bursts without AAC encoding. The VTT files describe the flash times and intended offsets for a compatible player you already use.

Generated and measured by StudioSignalLab on October 29, 2026. Shipped files are pinned by hash. Measurements can be repeated; different encoders, fonts or builds may produce different bytes. These examples contain no speech, music or hardware capture.

Start with an event you can identify twice

Use a visible clap or another sharp event you can record appropriately. In the saved file, find the first frame where contact is visible and the start of the matching sound. Listening is useful, but placing both events on a timeline makes the direction of the error less ambiguous.

Choose an event whose picture is clear. A blurred hand movement and a rounded sound onset leave more room for judgement than the clean pulses in our generated files. State the frame rate and how you selected the audio onset; do not report millisecond precision from a vague visual cue.

Make the same observation near the beginning, middle and end of a representative recording. The point is not that three observations prove reliability. They can reveal that the problem you were about to treat as one fixed delay is changing.

Give the gap a sign before opening the controls

Use this measurement convention: gap = audio-event time minus picture-event time. A positive result means the sound arrives later in the file. A negative result means it arrives earlier. This convention belongs to our worksheet, not to the sign or limits of an OBS control.

• Invented timeline example: Picture 1.000 s; sound 1.200 s; Measured gap: +200 ms; What it tells you: Audio is later; picture is earlier
• Invented timeline example: Picture 1.000 s; sound 0.800 s; Measured gap: −200 ms; What it tells you: Audio is earlier; picture is later
• Invented timeline example: Picture 1.000 s; sound 1.000 s; Measured gap: 0 ms at chosen resolution; What it tells you: No measured gap at this event

Convert frames without pretending every recording is 25 fps

For a constant-frame-rate timeline, milliseconds = frame difference ×1000 ÷ actual frames per second. Five frames at 25 fps are 200 ms; five at 30 fps are about 166.7 ms. Use the actual timeline rate, including a fractional rate when relevant.

Frame counting limits the precision of the picture observation. At 25 fps one frame spans 40 ms, so a one-frame judgement error matters. If the editor and source use different timing assumptions, resolve that before choosing a correction.

• Actual fps: 25; One frame: 40.0 ms; Five frames: 200.0 ms
• Actual fps: 30; One frame: 33.3 ms; Five frames: 166.7 ms
• Actual fps: 50; One frame: 20.0 ms; Five frames: 100.0 ms
• Actual fps: 60; One frame: 16.7 ms; Five frames: 83.3 ms

Choose the branch that matches the evidence

The following scenarios are invented diagnostic examples. They are not observations from an OBS session. More than one cause can produce the same symptom, so keep the original recording and change one variable at a time.

• Beginning / middle / end, or symptom: +200,+200,+200 ms; Working interpretation: A repeatable fixed mismatch; Next useful test: Test one source delay, then measure a fresh file
• Beginning / middle / end, or symptom: +40,+200,+360 ms; Working interpretation: Gap changes across the recording; Next useful test: Investigate timing stability and the capture chain; one offset is insufficient
• Beginning / middle / end, or symptom: Same file agrees in one viewer but not another; Working interpretation: Playback or interpretation differs; Next useful test: Compare source/timeline settings and another playback path before changing capture
• Beginning / middle / end, or symptom: Only one camera disagrees with the microphone; Working interpretation: Source-specific path deserves attention; Next useful test: Measure that camera separately; avoid moving every source

Use the appropriate delay control

Focusrite's OBS setup guide identifies Sync Offset in Advanced Audio Properties as a millisecond adjustment and says the required value depends on how the system processes audio and video. OBS separately documents Render Delay as delaying a source image. Those are two different places in the signal path.

We checked the OBS Studio 33.0.0 source: the Advanced Audio Properties dialog creates a Sync Offset field in milliseconds, with a range of −950 to 20,000, and passes the chosen value to the source sync-offset API. That is a version-specific control check, not a measurement of its effect on your recording. Confirm direction with a fresh short recording rather than copying the sign from our worksheet.

If the audio is consistently early, adding delay to that audio is a candidate correction. If the image is consistently early, delaying that image is a candidate. Check which source the control applies to in your installed build; our worksheet's plus or minus sign does not establish a supported input range.

Record the old setting before the change. Apply one small, measured correction to the earlier route and make another file. Recheck the same event positions. A change that makes one clap look right but introduces a different mismatch has not passed the test.

When the gap grows, stop chasing it with one offset

A fixed delay shifts the whole signal by the same amount. It therefore cannot remove a gap that is small at the start and larger at the end. Note the devices, connection paths, recording duration and source/timeline rates, then reproduce the problem with a simpler scene.

Keep the OBS log from the affected session and note any performance warnings you actually observe. Device timing, buffering, performance and an editor's interpretation are investigation areas, not conclusions you can draw from lip sync alone. Matching sample-rate labels does not prove that independent device clocks agree.

Likewise, remuxing a recording is a container handoff, not evidence that its timing has been repaired. Use the separate format/remux guide for that job. Do not overwrite the only recording while trying repairs.

What the original demonstrations establish

We generated six-second files with picture flashes beginning at 1, 3 and 5 seconds. The reference tone bursts are nominally aligned; the comparison bursts are 200 ms late. After H.264/AAC encoding, our decoded centre-pixel and audio-threshold check measured about 1.17 ms and 201.17 ms respectively. The roughly 1.17 ms onset difference belongs to the fade/threshold measurement; it is not measured OBS latency.

The video runs at 25 fps, and the test accepts a 10 ms audio-onset tolerance around the nominal offsets. Use the downloaded files for a timeline check in your editor. Your headphones, display and playback software have their own timing behaviour; these examples do not calibrate that chain.

Neither file demonstrates long-session drift. For that, use your own representative recording and the three-position worksheet above.

FFmpeg 5.1.2 decoded the encoded files. Their AAC first packet starts at −1024 samples (−21.333 ms) with 1024 skip samples and a presentation start of zero. The decoder honours that priming information; we measured the presented audio timeline and did not add 21.333 ms by hand. The audio onset threshold was an absolute sample value above 800/32768 after a 5 ms fade. Different onset choices can change the small residual.

Keep a correction another editor can understand

Save the original filename, source names, actual frame rate, event positions, measured gaps and the single setting changed. Keep the fresh test file beside that record. A useful handoff says which path was corrected and how the saved result was checked, rather than simply saying that sync was fixed.

If the problem remains, that small evidence package is a better support request than a list of settings copied from someone else's machine.