Kodi Audio Out of Sync playing file or after seeking

If it helps anyone, I’ve found that using the app on my phone, “AV Sync”, useful for measuring the audio sync error and getting more objective results.

It requires a video that has a synchronized flash / audio beep, I’ve been using the Spears & Munsil A/V sync sample. The app then displays the offset for each flash from the beep.

Using that, I’ve found the the commands from @cpm clearly do something, but it isn’t eliminating the audio sync offset for me.

Another, and this time very consistent, result is that each flash / second, I am seeing the offset increase by 1 or 2 milliseconds. This continues until a total increase of ~30ms is present, until the the offset will jump backwards ~30ms and the pattern repeats. Can’t say if this is a CE issue or just related to how 23.976 fps video works with 48 kHz audio - but it was very easily observable using the app compared to trying to eyeball the video.

I saw this yesterday - 30 rang a bell though seems trying to adjust before hitting 30ms:

and

1 Like

I am having this audio sync issue when I switch audio track from TrueHD to DD. This causes the movie to pause for a second and restart.

Then the audio is out of sync and Ugoos drops a frame very often.

I disabled DD transcoding and then tried it again. The audio sync issue doesn’t seem to appear anymore when switching audio tracks. It sometimes drops frames but it isn’t as regular/often as before disabling the DD transcoding.

There is also one, fast forward playback of dual layer Dolby Vision. Whether it is a single track or double track dual layer Dolby Vision, there will be audio and image synchronization issues. In addition, memory playback cannot switch audio tracks, which has not been resolved until now.

Is this a Kodi bug?

It’s not a Kodi bug, this is a Corelec bug that hasn’t been fixed yet, especially when playing dual layer Dolby Vision.

Both NG and NE memory playback have the issue of being unable to switch languages.

Probably because no other Kodi implementation can actually play Dual Layer DV - unless you know something?

1 Like

May I ask if the issue of not playing the dual layer Dolby Vision and memory playback has not been resolved yet? The problem is that the audio track cannot be switched through memory playback. In other words, it is not possible to continue playing the previously played audio track through memory playback, and the audio track cannot be switched. Do we also need to wait for the Kodi version update?

1 Like

For the first issue you mentioned, the cause has been identified by @Portisch here:

The decoder does not start at an I-frame after seeking apparently. Hopefully this can be fixed in one of the upcoming nightlies?

3 Likes

Using today’s nightly version, I solved the problem of unsynchronized fast forward audio and video. After waiting for the memory playback to be fixed later, I solved the problem of memory playback, and there were basically no major issues for me.

1 Like

any chance of another link to that test build please or guide to change my latency to the same? thanks

Not sure why this thread was marked as having been solved. That solution was for a different issue, audio sync issues are still present on the latest nightly builds.

Observation - Kodi passthrough is completely in sync under Android, starting with no delay on refresh rate change and with seeking. It seems like it starts out of sync but then starts to correct itself with no intervention about 2 - 3 times until it’s finally in sync.

2 Likes

Still out of sync on AM8 Pro, CE22 latest nightly. Skipping back/forward, pausing not working.

I may have missed something, have there been any changes that were expected to fix this?

See the latest message from @Portisch here: Nightly builds (NEW) - #2476 by Portisch

However, I think that this will only land in the 20241018 nightly, so I wouldn’t expect this change to be in already.

I didn’t understand that to be related to the audio sync problems that occurs with all file formats at all bitrates. Wait and test I suppose

I also was under impression that new experimental code was more for buffer-related stutter/framedrop issues than sync-related ones. What is annoying about this one is I can’t find a clear pattern, sometimes heavier files/remuxes don’t fail sync-wise on seek/pause while some web-dls do and vice versa (and they all do it via network or USB-storage).

But you would not test latest nightly to see if there are some changes? …

I did compile a build once I saw the changes, but that was late in the evening, had only tested it with one file before shuteye and didn’t have any sync issues with it (it was a remux with lossy DTS), but it’s not yet representative as I also had some files without bad sync on previous builds. I was planning to do more extensive test later today (in ~8-9hrs).