So looking at the code, the latency variable is displayed in seconds calculated from m_displayLatency which is calculated in various ways depending if defaults to fallbacks are used or not.
The value 0.166 is also interesting itself. That is very close to the value I have had set as a constant offset for a very long time - still had occasional sync problems - but an offset of that value definitely helped for the more “systematic” sync problem.
While some of the code look to have recently changed, i.e., some “learning” of a maximum error, I have had this issue for what feels like forever. Well before that work - and the problem isn’t limited to TrueHD.
Tried these commands a couple times but nothing happens. No pause o resyncs like you said. Vsyncoff value never changes.
Edit: I was watching some old stuff with mpeg2 SW decoder. That’s why the command didn’t work.
Anyway, video paused with echo 0 and starts to catch up with echo 1, but vsyncoff value remains the same.
Edit2: I should’ve tested more before making a post, sorry.
With audio sync test video I tried pausing and playing a couple times until I could get it grossly out of sync. If I quickly switch between commands nothing changes, but if I wait about a second it does something and the audio seems to start matching the video. I’m not good at telling if the audio is early or late, just that something seems wrong and this seems to help.
LG C1 connected to Anthem MRX-740 via eARC audio stays in sync while skipping around with both 23.976 and 59.94 frame rates. I remember having audio sync problems when I owned a Denon Receiver.
eARC is designed to support lip-syncing and it was more stable for me, perhaps even perfect, but then I observed that the audio was consistently delayed.
Seems to be something inherent to the way earc works,
On my Denon AVR there’s an ‘‘auto lipsync’’ option and without it, all my devices are OOS. I think this is the source of my audio sync problem on the Ugoos because I turned it off and I just set a fixed 150-200MS delay in Kodi and now the audio sync seems perfect and more stable than before, at least for the last 4 movies I watched. I don’t remember having any audio sync issue on the good old CE-20.5 though.
I tried out the commands and I did notice it can resync itself perfectly. However, it is not always perfect. For example, if you do it multiple times, if you wait a little between inputting the commands, it can still result in a +/- delay. I can’t find a direct correlation, only that you can do it as many times as you need to get to a perfect sync.
So it looks like the latency value is being calculated using this default method. By default, 3 buffers are used. Also the GetFPS() refers to the hdmi framerate output. By default in CE/kodi this does not always match the framerate of the files - framerate double is performed if possible, i.e., play a 25 fps files at 50 fps. Taking this into account, all the reported latency values align.
This latency value is used as a part of calculating the sync error.
I am thinking that being only calculated based on the output framerate shows that the link between the latency values reported over the hdmi signal are not making it way up into kodi? May explain some inconsistency…
Just posting my experience with this issue. It used to happen quite often when starting a movie (usually with a THD track) it would be out of sync from the beginning, but setting the “Delay after change of refresh rate” option to 2 seconds seemed to improve things a lot for me (not too sure why). I do still notice things going out of sync sometimes after seeking (or pausing/resuming) though.
When starting a file, I first have a larger audio sync error, i.e., ~ +7 frames / 250-300ms on 23.97 fps test file from Video Audio Sync Tests @ 23.98, 24, 25, 29.97, 50 & 59.94. After skipping back 10s this consistently reduces to + 4/5 frames. At this point we are back at the 0.166 offset that kodi is seemingly trying to use to somehow “compensate” in some form for an assumed display latency based on the number of presentation buffers. This pattern is repeatable at different frame rates - the error start very large and reduces after skipping back to the latency value from kodi.
After forcing this variable (m_displayLatency) in kodi to be 0. I am now consistently getting audio that is in sync (or at least much closer to) after skipping backwards to remove the large positive offset that occurs when I start playing a file.
Using the workaround by @jones3y above, I am now getting the audio to consistently playing in sync without needing to skip around after starting a file.
Test build for anyone interested in testing below. Based on the 21.1.1 release with the above variable forced to zero
Beginning to suspect the nonzero VSyncOff is a related, but slightly different thing. It is exactly zero for me for all non-fractional framerates in CE-20.5 and CE-21. However, for CE-19.4, it is always exactly zero for all, including fractional, framerates.
See me below post Kodi Audio Out of Sync playing file or after seeking - #37 by doppingkoala, but I was also seeing large audio sync errors for these framerates as well before forcing the m_displayLatency to be zero. After this change still shows nonzero values for VSyncOff for fractional framerates - but seems to eliminate the large consistent offset.
Very hard to tell, but I think from these examples everything (fractional and non-fractional) has ~ 20-40ms audio delay when I start playing, skipping can induce more delay, freerun_mode 0 then 1 though seems to bring it back as exact as I can tell spot-on from either the initial delay or the skipping additional delay.
1 Sec looks to do it for me, can do all in one line:
Just for clarity with the direction of the delay, you are seeing the marker is at ~ 1 or 2 position on the 23.98 fps video at the sound? And then skipping around make the marker go to a more negative value. Then when you enter those commands the marker moves back to the original ~ 1 or 2 value?
When starting the video the sound is on +1 (feels just after +1 maybe)
Applying the commands it feels bang on 0
Skipping in these examples goes back to +1
Skipping in other long length files it can move out further again more audio delay never looks to be audio is ahead.
I’ve experimented with everything that has been mentioned here so far: setting the 2 sec delay after the frame rate switch, toggling the freerun mode and setting the m_displayLatency=0. Unfortunately, I can’t say that any of those methods give me a consistent delay I could offset elsewhere, the results are pretty much all over the place.
I’m measuring the actual latency by recording the TV at 120fps, and then comparing the recording with the original file.