Webcam A/V Sync & Latency Meter Reference

Audio Offset

Before applying any delay, name the relationship you are measuring. Audio offset is the signed millisecond value that describes the timing gap between an audio stream and its corresponding video stream. A positive value means audio arrives before video; in broadcasting terminology this is called audio delay. A negative value means audio arrives after video. Offset is measured between two timestamps: the moment a sound event occurs in the audio stream and the moment the same physical event appears in the video stream, both measured against a shared clock.¹

In browser-based measurement, both timestamps come from performance.now(), a high-resolution monotonic clock that is intended for elapsed-time measurement and is not subject to system time adjustment. Comparing two performance.now() values from the same browser tab gives a precise, drift-free delta in milliseconds.¹

What is Audio Offset?

How audio offset arises from hardware

USB audio devices use isochronous endpoints for time-dependent streaming, and Microsoft documents a 1 ms frame interval for full-speed isochronous transfers.² USB video devices follow a separate UVC driver path and may use compressed formats such as MJPEG or H.264, so their delivery path can differ from the audio path even when both devices are connected to the same computer.³ The difference between those path lengths is the audio offset.

On many USB webcam setups, audio reaches the browser before the matching video frame. That gap is the audio offset for that hardware combination, and the exact value depends on the camera, microphone, drivers, USB topology, and current system load. The offset is not a fixed property of the camera alone; it is a system-level measurement that captures the combined latency of every stage in both the audio and video pipelines, which is why the same camera can measure differently on two machines with different USB controllers, driver versions, or background CPU loads.

The regular service interval used by isochronous audio transfers explains why audio latency is often lower and more predictable than video latency. Isochronous transfers reserve bus time for steady-rate data, but Microsoft notes that delivery is not retried if an error occurs. Video follows a different device-class path and can be affected by compression, decoding, driver buffering, and USB bandwidth conditions. This structural difference is why USB webcam measurements often show audio arriving before video, but the sign and size should always be measured for the current setup.

Hardware path behind the signed value

The sign tells you which stream needs delay before you open recording software. A positive offset delays audio, while a negative offset uses buffered audio so the source aligns with the earlier video frame. Understanding which path is slower helps you diagnose unexpected changes: if your offset suddenly flips from positive to negative, something shifted the balance between the audio and video pipelines rather than just adding a small amount of delay to one side.

Treat a sudden sign flip as a symptom, not a one-off measurement. Before changing the OBS value, check whether a driver, USB connection, or app update altered one pipeline more than the other. A changed sign usually means the audio and video paths no longer relate the way they did at your last calibration, so re-measure from scratch rather than nudging the old number.

Correcting audio offset in recording software

Recording software applies an offset correction by delaying the faster stream until it matches the slower stream. Because audio often arrives before video, the correction adds a fixed delay to the audio source equal to the measured offset. In OBS Studio this is the Sync Offset field in Advanced Audio Properties.⁴ In Streamlabs OBS, the corresponding control is the Sync Offset column in Advanced Audio Settings rather than a separate Audio Delay filter.⁵

Entering an accurate offset reduces lip-sync desync visible in recordings and streams. The correction must be re-applied when hardware, drivers, or software change, because any of those changes can shift the offset. Even something as simple as a Windows power-plan change from Balanced to High Performance can alter USB controller polling behavior and shift the measured offset by a small but perceptible amount, so it is worth re-measuring after any system-level configuration change that affects CPU or USB scheduling.

When to update the offset correction

The audio offset for a specific webcam-and-microphone combination on a given machine usually stays relatively stable between sessions if nothing changes. Hardware changes, such as adding or removing a USB device that shares the host controller, can change bus contention. Driver updates from webcam manufacturers or USB chipset vendors can change the processing pipeline. OS feature updates can also touch USB audio or video scheduling behavior. After any of these changes, run the five-clap test and update the OBS Sync Offset or Streamlabs Sync Offset control to the new value. Entering an outdated offset produces a correction that is no longer accurate for the changed conditions.

Why the sign matters before correction

The sign of the offset tells you which stream is slower. A positive value means the audio arrived before the video, so the correction delays the audio source. A negative value means the audio arrived after the video, so the correction uses a negative offset to align the audio with the earlier video frame. If you ignore the sign and only copy the magnitude, the correction can move the wrong stream in the wrong direction.

Try in the tool

A/V Sync

Measure A/V sync before deciding whether the audio or video path needs correction. A/V sync - audio-video synchronization - is the alignment of the audio and video tracks in a recording, live stream, or video call so that sounds occur at the same perceived time as the visual events that produced them. When a person claps their hands on camera, the sound and the visible hand impact should reach the viewer at the same moment. When they do not, viewers perceive an uncanny "dubbing" effect even if they cannot immediately identify the cause. Small residual gaps still matter during focused editing and live monitoring.

Human perception is sensitive to A/V sync errors above approximately 45 ms. ITU-R BT.1359-1 reports average detectability thresholds of audio ahead of video by about 45 ms and audio behind video by about 125 ms under test conditions.¹ EBU R37 gives stricter broadcast-chain limits for sound-before-picture and sound-after-picture timing at emission.²

What is A/V Sync?

Why A/V sync desync occurs in webcam setups

In a webcam streaming setup, audio and video can travel through separate hardware and software paths from the performer to the recording software. USB audio uses isochronous endpoints for steady-rate data.³ A UVC webcam follows a separate driver path and may use formats such as MJPEG, DV, or H.264.⁴ The two paths can take different amounts of time, so a fixed A/V offset can appear even when both devices are connected to the same computer.

Because video often includes sensor readout, image processing, compression, driver buffering, and decode, the video path is commonly the slower path in USB webcam measurements. That does not mean every setup has the same offset; the measured value still depends on camera, microphone, drivers, USB topology, and current system load.

Webcam-specific offset versus tolerance standards

Standards describe what viewers are likely to notice, not the correction your computer needs. A setup can pass a broad tolerance threshold and still show a visible clap mismatch in a test recording, especially when the camera, microphone, and recording app each add their own timing behavior. Measure the actual A/V offset first, then use the tolerance guidance to decide how much residual error remains after correction.

The clap test captures exactly the combination your machine presents to the browser. A published threshold from a broadcast standard does not account for your camera's compression or your USB controller's scheduling, both of which enter the number you measure. Use the standard to judge whether a measured residual is acceptable, not to skip measuring in the first place.

Why video processing can take longer than audio processing

The steps video must complete before reaching recording software are more complex than the audio path. A USB webcam may process the sensor image, apply camera-side adjustments, compress the stream, pass it through the UVC driver, and then decode it in software. Audio uses a steadier isochronous delivery model, while video formats and driver paths vary by camera and Windows support. The result is a structural timing gap that should be measured for the current setup rather than copied from another machine.

Standards for acceptable A/V sync

ITU-R BT.1359-1 is the key subjective-threshold source for broadcast A/V sync discussions. It reports average detectability thresholds of about 45 ms when sound is ahead of vision and about 125 ms when sound is behind vision. These perceptual limits come from controlled listening and viewing tests, and they represent the point where a majority of observers begin to notice the mismatch rather than the point where every viewer finds it objectionable.¹

EBU R37 is stricter for broadcast emission. It recommends limiting sound-before-picture and sound-after-picture timing at the output intended for emission, which is why professional production targets are tighter than the broad viewer-detection thresholds.² The EBU limits are designed for broadcast chains where multiple encoding and transmission stages can accumulate additional sync errors at each step, so the per-stage budget must be tighter than the final viewer perception threshold to keep the total chain within acceptable bounds.

Streaming platforms can add their own transcoding and buffering, so use these standards as tolerance references rather than as a promise that a live platform will correct a bad source stream. For production work, target a small residual offset after correction and verify it in the actual recording or stream. Twitch and YouTube do not apply any A/V sync correction to incoming streams; they transcode and deliver the signal exactly as received, which means any sync error present in your OBS output will be visible to every viewer regardless of the platform.

Using standards as a correction target

The perception thresholds are a starting point, not a reason to ignore smaller offsets during setup. A 30 ms gap may be tolerable in casual viewing, but a clap test makes it easy to see. For production work, aim to get the measured residual as close to zero as practical, then verify the final recording or stream before publishing. Keeping the residual under 20 ms ensures the alignment stays well within the perceptible threshold for all viewers, even those who are actively paying attention to lip-sync accuracy during close-up segments.

Try in the tool

Sample Rate Mismatch

When the sync gap grows after the first minute, sample rate mismatch is the likely cause. Sample rate mismatch is the condition where two or more audio devices in a recording chain operate at nominally identical but physically different clock rates. Each USB audio device uses its own clock source to generate its sample-rate timing; USB audio codec clocking examples are specified in parts per million, such as a 12 MHz clock with ±500 PPM accuracy.¹ If two devices are each off in opposite directions, their actual clocks can differ even when both are nominally set to 48,000 Hz.

Over a one-hour recording, a 100 PPM discrepancy at 48,000 Hz means one device generates 288 additional audio samples compared to the other. At 48 samples per millisecond, that 288-sample difference represents 6 ms of drift per hour from sample rate mismatch alone.

What is Sample Rate Mismatch?

How sample rate mismatch causes drift in practice

Recording software like OBS mixes multiple audio sources at a fixed output sample rate. When an input device runs at a slightly different rate, OBS resamples its output to match the mix rate. The resampling is mathematically correct and eliminates audio-to-audio drift between sources. Yet the video clock is a third oscillator, the USB host controller that times video frame delivery. If the video clock drifts from the resampled audio rate, audio and video accumulate desync over the session.

A common source of larger drift is mixing audio from a USB microphone at 44,100 Hz with video from a camera expecting 48,000 Hz in OBS. The resampler converts 44,100 Hz to 48,000 Hz, but at a slightly different rate ratio each time depending on both oscillators' momentary frequencies. Setting all devices to 48,000 Hz eliminates the cross-sample-rate conversion entirely.

OBS resamples audio input sources to match its output sample rate when they differ.² The resampling is mathematically precise and corrects the immediate audio-to-audio timing difference between devices. However, resampling does not correct the accumulating difference between the resampled audio clock and the video host controller's clock, because the video clock runs independently of the OBS audio mix rate. Setting all devices to the same sample rate eliminates the audio-to-audio resampling step, reducing one source of clock divergence. The remaining divergence between matched audio clocks and the video clock accumulates at a much slower rate, typically 3–6 ms per hour at 50 PPM tolerance.

Why matching audio rates does not lock video

The video clock is not the same oscillator as your microphone or audio interface. Matching sample rates removes the systematic audio-to-audio conversion, but the USB controller that delivers video frames still has its own timing path. That is why drift checks should compare the webcam-to-mic offset at the start and end of the same recording session. Even with perfectly matched audio rates, the independent video clock can still accumulate a small residual drift over very long sessions.

Plan to run the start and end comparison on the longest session you actually produce. A 30-minute test hides drift that only becomes obvious after two hours, because the independent video clock keeps accumulating at its own rate. If your content routinely runs long, measure at the one-hour mark as well so the residual stays within the threshold you care about.

Diagnosing and fixing sample rate mismatch

To confirm sample rate mismatch as the source of your drift, measure the A/V offset at the beginning and end of a 30-minute test recording. If the offset increases by 10 ms or more over the session, mismatch is present. Open Windows Sound settings and set every audio device to 48,000 Hz / 24-bit.³ Open OBS Settings > Audio and set the Output Sample Rate to 48 kHz. Re-record the test session and remeasure.

For macOS users, open Audio MIDI Setup, select each audio device, and set its sample rate to 48,000 Hz.⁴ The same principle applies: matching all device clocks to the same nominal rate reduces the inter-clock drift to the random oscillator tolerance rather than a systematic offset.⁵

Matching sample rates in Windows and macOS step by step

On Windows 11, open Settings > System > Sound and click on each input device. In the device properties, navigate to the Advanced section and set the format to 48000 Hz. Repeat for every connected microphone, headset, and audio interface. If a device does not appear in Settings, open the legacy Sound Control Panel via Control Panel > Hardware and Sound > Sound, click each device in the Recording tab, open Properties, and set the Default Format on the Advanced tab. On macOS, open Applications > Utilities > Audio MIDI Setup, select each audio device in the left panel, and set the sample rate to 48000 Hz. Apply these steps to every audio device in your chain to eliminate cross-device sample rate mismatch.

Confirming the fix with a second drift check

After matching sample rates, run the 5-clap test again at the start and end of a 30-minute recording. If the offset stays within 10 ms, the sample-rate fix is working for that session. If the offset still grows, check for firmware updates, USB hub instability, or a device that is still set to a different sample rate. A persistent drift after matching rates often points to a single device running at an unexpected frequency, so double-check every audio endpoint in your chain.

Try in the tool

Audio Pipeline Latency

The microphone path is the fast half of webcam A/V sync, but it still has a measurable delay. Audio pipeline latency is the total delay from the moment a sound event occurs at the microphone capsule to the moment the corresponding audio data becomes available in software: the browser, OBS, or a DAW.¹ For a class-compliant USB microphone, this path includes the ADC sampling stage, USB isochronous packet assembly, USB host controller scheduling, OS audio driver buffer, and Web Audio API handoff.²

On a typical Windows 11 machine with a USB condenser microphone, the total audio pipeline latency from capsule to browser runs between 10 and 30 ms.³ This is significantly lower than the video pipeline latency for a USB webcam (60–130 ms),⁴ which is why the audio stream is the "fast" path and why the measured A/V offset almost always shows audio arriving before video.

What is Audio Pipeline Latency?

Stages that contribute to audio pipeline latency

Inside a USB microphone, the capsule membrane vibrates in response to a sound. An analog-to-digital converter samples the voltage at the microphone's sample rate (48,000 samples per second for most USB microphones).² Each sample is buffered into a USB isochronous packet. USB full-speed isochronous transfers deliver one packet per 1 ms frame; the OS services each frame at 1 ms intervals as part of the USB audio class specification.⁵

Beyond the USB hardware, the OS audio driver adds its own buffer, typically 5–20 ms for standard Windows WASAPI or macOS Core Audio operation.⁶⁷ This buffer smooths out irregular delivery intervals from the USB layer. The Web Audio API then picks up the samples from the OS audio buffer for processing.¹ The total from capsule to Web Audio API is the audio pipeline latency visible in browser measurements.

Why driver buffers dominate the audio path

The USB transport itself is regular, but the driver buffer is what makes audio practical for normal applications. A small buffer keeps monitoring responsive; a larger buffer protects against dropouts when the CPU or USB bus is busy. That trade-off changes the microphone side of the A/V offset without changing the webcam video path. On Windows, the WASAPI audio stack typically adds a larger buffer than macOS Core Audio, which means the same USB microphone can measure a different total pipeline latency depending on the operating system. Choosing the smallest stable buffer size your system can handle without dropouts keeps the audio pipeline latency as low as possible while still protecting against glitches during heavy CPU or USB bus load.

Watch the buffer setting when you switch operating systems or reinstall audio drivers. A fresh driver install can reset the buffer to a larger default, which adds a few milliseconds back onto the audio path and shifts the measured offset. Re-measure after any audio driver change so the OBS correction reflects the buffer your system is actually using.

How the 1 ms isochronous guarantee keeps audio latency low

The 1 ms isochronous service interval that keeps audio pipeline latency low is defined in the USB 2.0 specification and maintained in USB 3.x for backward-compatible audio class devices. The host controller divides each USB frame into 125 µs microframes (USB 3.x) and services isochronous transfers in every microframe, giving USB audio class devices guaranteed, regular delivery slots.⁵ Because audio data arrives in these guaranteed slots, the OS audio driver can buffer only a small number of samples and still deliver them on schedule. The total OS-level contribution to audio pipeline latency is typically one to three 1 ms frames, keeping the audio path well under 10 ms for the USB transport and driver portion alone.

Audio pipeline latency vs video pipeline latency

Video pipeline latency for a USB webcam starts at the camera sensor, travels through in-camera ISP processing (noise reduction, white balance, compression at MJPEG or H.264), USB transfer scheduling, kernel video driver buffer, and browser video decode. Each step adds latency that audio does not encounter, and the cumulative effect of all these stages is why video typically arrives 60 to 130 milliseconds after the matching audio event in a standard USB webcam and microphone setup.⁴

The structural asymmetry (audio using isochronous 1 ms USB frames versus video capture and encoding paths with variable scheduling) means audio will usually arrive earlier than video in a USB webcam system. The A/V offset you measure with the 5-clap test is the quantified expression of this asymmetry for your specific hardware combination. This asymmetry exists at the USB protocol level, so it applies regardless of which browser, operating system, or capture software you use; any application that receives separate audio and video streams from USB devices will encounter the same fundamental timing gap.

The structural asymmetry between audio and video USB scheduling means that shortening the audio pipeline latency to zero would not eliminate the A/V offset problem; it would worsen it. If audio arrived instantly at the browser while video took 80 ms, the offset would be 80 ms with perfect audio latency. The practical solution is to accept the gap, measure it precisely with the five-clap test, and apply the correction in recording software. Adding an 80 ms artificial audio delay buffer to produce a zero offset in the browser would add 80 ms of latency to your monitoring chain, making your own voice in headphones noticeably delayed. The OBS Sync Offset corrects the recorded output without affecting your real-time monitoring.⁸

Why lower audio latency does not mean better A/V sync

A low-latency audio interface can make the measured A/V offset larger, not smaller, because it makes the audio path even faster than the video path. The A/V sync correction is relative: you are aligning the audio and video streams at the output, not minimizing the microphone-to-headphone monitoring delay. This is why the browser measurement still matters even with a fast audio interface.

Try in the tool