Your audio drifts because two clocks disagree

Sync is fine for ten minutes. By the end of the hour your mouth and your voice have parted company. Nothing changed, which is the clue.

4 August 2026Audio

A sync offset is constant. You measure it once, dial it in, done.

Drift is different. It grows. That tells you something is counting, and two things are counting at different speeds.

What is actually happening

Every audio device has its own crystal. Your interface says it runs at 48,000 samples a second. It runs at 47,999 or 48,002. The tolerance is small and the error never resets.

Your computer expects exactly 48,000. Over an hour a few parts per million becomes a few hundred milliseconds. Software patches the gap by dropping or repeating samples. You hear clicks, or you watch the lips slide.

The mismatch that makes it worse

Now add a device set to 44,100 in a project running at 48,000. Something has to resample in real time, forever, on top of the clock error.

Windows makes this easy to get wrong. Each device has its own default format in the sound control panel. A headset at 44.1, an interface at 48, a capture card at 48. OBS resamples all of it.

Giving them one clock

• macOS. Build an aggregate device and nominate a clock source. Turn on drift correction for the others. The system resamples them to the master.
• Windows. Match every device format. Where an interface exposes a word clock or ADAT input, feed it the same clock as its neighbour.
• USB microphones. Each one is a separate clock. Two USB mics in one show is two clocks that will part company. One interface with two inputs is one clock.
• Capture cards. Audio arriving embedded over HDMI carries the source device's clock, not yours.

How to prove it is drift

Record a two-hour session to disk. Clap at the start and clap at the end. Measure both offsets.

Same offset both times means a fixed delay. Dial it in and move on. A bigger offset at the end means clocks. No delay setting will fix that, because the number you need keeps changing.