Lip sync issues (audio is delayed)

I am experiencing lip sync issues where the audio is behind the video by 70-120 ms (depending on a few variables). I can replicate this using a Vero 4K+ and a RPI4, both on 2023.01. I can work around this by deactivating video hardware acceleration, which allows audio to gain up to 150 ms relative to video (so that audio is now always ahead of video). The workaround is not usable as most videos in my collection can’t reliably play without hardware acceleration.

For some time I suspected I was seeing a lip sync issue, but I never bothered investigating it until I got a new TV + soundbar combo. I assume this new combo pushed the audio delay beyond a reasonable threshold which started bothering me, so I started a long process to investigate (and learn about) audio-video sync issues. I can’t yet indicate which OSMC version this delay was introduced in, but it it’s happening on the current version.

I tested this with Vero 4K+ and RPI4, using 2 differnet TVs (TV1: Samsung Q90R, TV2: Samsung QN95B + Samsung Q800B soundbar). TV1 does not have a soundbar. TV2 has a soundbar, but was also tested with TV speakers only with a similar result. Contrary to my initial suspicions, I have confirmed the TVs are not introducing the audio delay. Since I’m observing this on both Vero 4K+ and RPI4 I guess the issue is not platform specific.

I’d like to know if this is a known issue with Kodi or OSMC, and what kind of troubleshooting steps or logs are required.

Sanitized logs while playing a test file on Vero 4K+ while connected to TV2 & soundbar (Vero 4K+ → TV → soundbar):

Past threads from 2019 on this topic:

Audio-video delay testing:

  • Test files: 1920 x 1080 Files - Sync-One2
  • AV Sync test app:
  • Notes:
    • I have used both a MacOS and a Linux device as a reference for the zero delay / in-sync state. I then used that reference to obtain a fairly reliable A-V sync delay offset for each of the 3 Android devices I tested with. This was needed because each of the 3 Android devices had different reading of the same reference delay.
    • In previous iterations of my tests, I was recording the TV while displaying various test A-V sync videos, then playing back at reduced speed to more easily read the delay. I have found the app approach to be a lot more reliable, but the results were consistent.

Is this for all videos? If yes, play a video, go to the audio settings, adjust the Audio Offset until it’s in sync and then Set As Default For All Media.


Please change Adjust Refresh Rate to Always.

I note your soundbar supports AC3, but not DTS passthrough.
AAC, in your sync test video, obviously cannot be passed through.

Do you experience issues when playing AC3 content?
Do you experience issues when playing content with DTS soundtracks?

Given the limitations of your system (Samsung – so no DTS license); I’d be inclined to disable passthrough; use LPCM and configure a global audio offset.

Indeed. This will only work when passthrough is disabled, but given the fact that the poster is using a soundbar, I think LPCM would suffice just fine.

Thank you all for the replies.

Thanks for the suggestion, unfortunately it’s not as easy as that because the audio delay changes with the various formats. There isn’t a single offset I can use that will work for every case. I have tried compensating with a file-specific delay, but it is not something I look forward to doing on a continued basis.

It is already set to “On start / stop”, including during the test. Is there any practical difference between that and “Always” when it comes to the audio delay issue?

The soundbar I think is a red herring, as is the passthrough option. I can observe the same audio delay with the soundbar disabled (TV2) and with no soundbar (TV1). I can also observe the same audio delay with passthrough enabled / disabled, so I believe it is not a factor.

AAC was the format in the test file I submitted logs for, the other format I tested with is PCM. I am trying to keep number of variables to a minimum to make it easy for anyone else to try to replicate.

It’s difficult to judge when watching content, hence why I tried to use the testing methodology described. As stated in the OP, I subjectively felt something was off for some time, but due to life and priorities I never bothered investigating. Now I made the time and can put into numbers what I subjectively felt was off.

If you can provide a similar sample file with AC3/DTS I would be happy to test. For most of my collection I believe AC3/DTS is not relevant, as I’ve been happily watching the content on TV speakers for a long time.

Thanks for the suggestion. That does sound like a work-around, but as stated earlier I’d like to investigate the root cause and possibly find if it is fixable.

Offtopic: I was aware Samsung TVs do not decode DTS, but they do have the option to passthrough the bit stream to the soundbar, which I believe supports DTS. I have not tested this theory though.

To make the problem statement clearer, I’d like to emphasize:

  • The problem happens with/without a soundbar
  • The problem happens with/without audio passthrough enabled in Kodi
  • The problem does NOT happen with 2 other HDMI sources connected on via the same HDMI port & cable, using the same exact settings on the TV
  • The problem does NOT happen with video hardware acceleration disabled on Vero 4K+.

Even though I appreciate the suggestion for the audio offset workaround, I have not yet given up on finding more understanding of the problem and possibly a fix. To help eliminate any errors in procedure or assumptions on my side, it would be great if anyone else can re-run the same tests and measure the results with the same methodology.

Given all the video processing TVs nowadays do, I’d expect the video to be delayed, not the other way around. So it is surprising to find audio is delayed.

Note: I plan to roll back to 2022.03 within the next couple of weeks due to the CEC issue described in 4k+ CEC EARC issue and HDMI-CEC seems to stop working after a couple of hours. I’d appreciate any feedback or test ideas soon so I can run them on the current version.

Regrettably, I can’t use the same methodology because my phone is too old to support that app. But I did what I’ve been meaning to do for a while. I set up a photocell in front of the screen and on an oscilloscope compared the output from that with the signal from the headphone socket on my TV (Panasonic E700). Vero directly connected to the TV.

With HW acceleration and using the same test clip you tried I get a consistent 90ms delay (audio behind video). Without HW acceleration it’s < 20ms delay. In both cases, the audio sync adjustment works as expected. So I guess that’s similar to what you found although the fact that the video pulse is shorter than the audio pulse complicates measurement and may affect the comparison.

However, if I put another device between Vero and the TV (actually a HDFury Vertex) then the delay with HW acceleration increases to about 110ms and delay without HW becomes about 70ms. Also the response to adjusting the audio sync seems somewhat random. It’s more consistent if I restart the video after making an adjustment. It seems the Vertex is massaging the signal in some way and I suppose an AVR or soundbar would have to do something similar. You don’t say whether your soundbar is between the Vero and TV or using ARC and we can’t tell from the EDID for some reason.

Apparently most people don’t notice a 90ms delay - I can’t say I notice the issue day-to-day. But we could have a look to see if it can be improved.

Edit: I have other clips intended for testing lip-sync and of those that I can use the same technique to measure the delay the delay is less than with the clip you tested with. It looks like there’s some uncertainty amongst the experts about exactly how the audio should be timed relative to the video.

1 Like

Thanks for replicating the test and sharing your findings. Given the setup, I assume your test to be more accurate, but I’d also be curious about the video processing latency of your TV.

In my case, the Vero 4K+ is directly connected to the TV, and the optional soundbar is also connected via HDMI to a dedicated port on the TV, no daisy-chaining involved.

I’m not familiar with the kind of knobs and levers available to the developers to address the hardware acceleration latency. Can anyone set any expectations whether this could theoretically be improved at all, and under what kind of hypothetical timeline? Thanks.

Personally, I don’t know in detail how lipsync is supposed to work. AIUI most audio streams (but not all?) are timestamped. So players should at least be able to send out audio in sync with video over HDMI. But HDMI doesn’t pass on those timestamps. Even if it did, AVRs and soundbars don’t know how long it takes a display to process video. There’s provision for a ‘latency’ value in the EDID but we rarely see that in TVs - more common in projectors. Then AVRs don’t always respect that latency value - many have a switchable ‘auto lipsync’ setting as well as a manual adjustment.

You would think an AVR connected by (e)ARC, as yours is, would synchronise better than one between the source and the display.

Maybe someone thought “Video takes longer to process than audio but we don’t know how much longer. Let’s delay the audio a bit so the chances of them syncing are better.”

From what you’ve measured on your gear, if you set the audio to say 50ms advance you ought to find that the best compromise.