Lip sync and audio delay: why your AVR's setting isn't the whole fix

I had a client's Denon flagged at "50ms lip sync offset, applied, done" in the setup notes from the previous installer. It wasn't done. The mouths still moved about a frame and a half ahead of the voices on anything sourced from the built-in streaming apps, but sat dead-on with the Blu-ray player. Same room, same speakers, same AVR. The lip-sync slider was masking one delay source while a second, completely different delay source sat untouched underneath it. That's the bit nobody explains properly: the lip-sync control on your processor is a single number applied to a problem that usually has two or three independent causes, each with its own magnitude, and they don't always move together.

I've spent a fair chunk of my working life around signal timing, first in electronics design, now poking at AVRs with an oscilloscope for fun on a Tuesday night, and lip sync is one of those things that looks trivial until you actually try to fix it properly across every source on a system. It isn't trivial. It's a chain of independent delays that happen to be additive, and your one slider only compensates for the sum, at one point in time, for one source.

Where the delay actually comes from

Video processing is slow. Audio processing is comparatively fast. That mismatch is the entire problem, and it exists at multiple points in the chain simultaneously.

Your display does its own video processing: scaling, deinterlacing, frame interpolation if you've left motion smoothing switched on, HDR tone mapping, sometimes a full colour-management pipeline if it's a decent projector. All of that costs time, and none of it happens to the audio signal, because the audio never goes near the display's processor. On a projector like the Sony VPL-XW5000ES the video path is well-optimised, but "well-optimised" for a projector still means single or low double-digit milliseconds of processing latency, sometimes more with certain HDR or frame-rate conversions active.

Then there's your AVR or processor. Decoding Dolby Atmos or DTS:X, running room correction, doing bass management and upmixing all takes processing cycles. A well-designed unit like the Denon AVR-X3800H keeps this tight, but it's not zero, and it's not identical across every audio format the unit supports. Decoding a lossless Atmos bitstream off a UHD Blu-ray is a different computational job to decoding the lossy audio bundled inside a streaming app's video container, so the two paths genuinely can take different amounts of time inside the same box.

Then there's the source itself. A smart TV's built-in streaming app frequently buffers and processes audio and video separately before they even reach your AVR over HDMI, and that internal handling varies by app, not just by TV. This is the part most people never think to blame, and it's often the biggest single contributor when the same AVR behaves differently source to source.

Why one slider can't fix all of it

The lip-sync adjustment on your AVR is a fixed audio delay, usually adjustable in small millisecond steps, that you dial in to compensate for the display's video latency. It assumes one thing: that the video latency is constant regardless of source. It isn't, for the reasons above. Set it correctly for your UHD player and it'll drift for your streaming app. Set it for the streaming app and the Blu-ray player will sound early.

Some AVRs let you store lip-sync offsets per input, which is the only way to actually solve this properly rather than compromise across sources. If your processor has that option, use it. Denon, Marantz and several others support per-input audio delay memory; check your manual rather than assuming, because the menu depth varies and it's easy to miss. It's genuinely one of the more underused features on a modern AVR, buried a few menus deep specifically because most owners never go looking for it.

There's also HDMI's own lip-sync handshake, part of the HDMI specification maintained by HDMI Licensing Administrator, which is meant to let the display report its processing delay back to the source device automatically so the audio can be delayed to match without you touching anything. In practice this works inconsistently across TV and AVR combinations. Some manufacturers implement it properly, some implement a version of it that reports an inaccurate figure, and some third-party streaming boxes sitting in the chain (an Apple TV or a games console, say) break the handshake entirely because they sit between the true source and the display and don't pass the reporting through correctly. When that handshake fails silently, your AVR either applies no automatic correction or applies the wrong one, and you'd have no way of knowing without actually testing it by ear or by scope.

How I actually measure it, not guess it

Guessing lip sync by eye is unreliable past a point, because your brain has a surprisingly wide tolerance window and adapts to small offsets within a few minutes of viewing, which then resets your sense of "normal" and makes the next test less accurate. The AES and various broadcast standards bodies generally treat delays under roughly 20 to 25 milliseconds as imperceptible to most viewers, with audio-leading-video being noticed sooner than audio-lagging-video, which is the more common real-world direction anyway given how much slower video processing tends to be.

The properly rigorous way is a clapperboard test signal, or even just clapping your hands in frame of a phone camera set to a high frame rate, then counting the frame offset between the visual clap and the audible clap in playback. At 60 frames per second each frame is about 16.7 milliseconds, so a three-frame offset is roughly 50ms, which is audible and worth correcting. This costs you nothing and takes two minutes, and it's more reliable than trusting your gut while half-watching a film you've already seen.

For each source, run the test, note the offset and direction, and store it against that HDMI input if your processor allows per-input memory. If it doesn't, you're stuck choosing a single compromise value, and I'd bias that compromise toward whichever source you use most, not the worst offender.

The streaming app problem specifically

This is where I get the most calls, and it's rarely the AVR's fault. Smart TV streaming apps process audio and video through the television's own decode pipeline before either signal reaches your AVR, and that pipeline differs app to app on the same television, because each app is built by a different company with its own buffering and decode choices layered over the TV manufacturer's operating system. Netflix's implementation on a given TV can behave differently to the same TV's YouTube app, purely down to how each app buffers and hands off audio versus video internally.

If you're chasing consistent lip sync across every streaming service, my honest advice is to stop using the smart TV's built-in apps altogether and run everything through one external streaming box instead, so at least the video-processing variable is constant across services. It won't fix the AVR-to-display baseline offset, but it removes one entire layer of inconsistency, and in my experience it's the single change that stops the "it's fine on the player but wrong on Netflix" complaint. I'll admit I resisted recommending this for years because it felt like patching over a manufacturer problem rather than fixing it, but the manufacturers haven't fixed it, so patch it is.

Where bass management and room correction fit in

Worth separating two things that get confused: lip-sync delay compensates for video processing time versus audio processing time, a source-to-source problem. Speaker distance and subwoofer delay in your room correction setup, whether you're running Audyssey, Dirac or a manufacturer's own system, compensate for the physical distance sound has to travel from each driver to your listening position, which is a completely different calculation solving a completely different problem. Getting your subwoofer's delay wrong makes bass sound disconnected from the front stage; getting lip sync wrong makes dialogue sound out of step with mouths. They're both timing corrections, but conflating them when troubleshooting wastes time. I've had installers chase a lip-sync symptom by re-running speaker distance calibration, which does nothing, because the two systems don't share a clock reference in that sense.

If your subwoofer integration is off it's worth reading up separately, because the fix is a different measurement entirely and the symptoms, while both being "timing" issues, don't overlap in cause.

What actually matters when you're setting this up

Test every source separately, don't assume one AVR setting covers HDMI input two and HDMI input four identically. Use per-input delay memory if your unit has it, buried menu or not. Bias any single compromise value toward your most-used source. Consider consolidating streaming apps onto one external box if you're chasing consistency across services rather than a single title. And accept that under about 20 to 25 milliseconds you're chasing a problem your eyes and ears likely won't reliably detect anyway, so there's a point of diminishing returns where I'd stop fiddling and just watch the film.

None of this needs to be expensive or complicated to sort properly. It needs about fifteen minutes with a phone camera and the willingness to test each source individually instead of trusting the last person who touched the menu, previous installer included.

If you're building a system from scratch and want the wider component picture before you get into this level of detail, our guide on building a home cinema: the core components covers where a processor like the Denon AVR-X3800H (check price) sits relative to your display and speakers, which is worth reading before you start chasing millisecond offsets on a system that isn't otherwise set up correctly.

— Marcus Vale, Editor