Kodi Audio Out of Sync playing file or after seeking

General
103

Yes, at this version and also one before to see the difference.

1 Like
104

TrueHD 7,1 is always more OOS vs other types on my setup

105

But is it now a constant offset with latest nightly?

106

@Portisch yes with a quick test with this advancedsettings and a couple of skip forward on the remote, offset is the same. Will do some more testing later , but thanks!

<advancedsettings>
  <video>
    <latency>
      <delay>0</delay>
      <refresh>
        <min>23</min>
        <max>24</max>
        <delay>175</delay>
      </refresh>
    </latency>
  </video>
</advancedsettings>
2 Likes
107

20241108_kodi.log (1002.2 KB)
20241109_kodi.log (1.0 MB)
20241111_kodi.log (1.0 MB)

Results using three nightly versions, the 20241109 one that was discussed, the previous one, and the new one for the sake of it.

File used was: Audio sync/Audio_Video_Sync_23.976_TEST TrueHD DTS-HD DDP DD PCM.mkv from 23.9976 link from Kodi Audio Out of Sync playing file or after seeking - #90 by R3S3T_9999

Was testing with the DD+ audio track.

For all the tests started the video, measured the offset, skipped back 10 sec by pressing left once on my remote, measured the offset and then stopped the video.

Approximate delay for each tests are

20241111 20241109 20241108
Initial audio delay 215 ms 215 ms 350 ms
Audio delay after skip 285 ms 320 ms 280 ms

Other testing on 20241111:
Will test in more detail later, but when using the TrueHD track it did appear to have both more consistent results and a lower delay than the DD+ track.

108

Please also enable audio/video timing in components.

All again…

109

Ahh, all three versions?

110

@Portisch Also found something that might be worth you testing to see if you can replicate the issue.

By setting the advancedsettings.xml as follows (with the overly large value for the delay)

<advancedsettings>
  <video>
    <latency>
      <refresh>
        <min>23</min>
        <max>24</max>
        <delay>500</delay>
      </refresh>
    </latency>
  </video>
</advancedsettings>

The differences in the change in audio sync become much more obvious - to the extent I am seeing some consistency in results. This has also highlighted differences in behaviour between TrueHD and DD+.

With the above advancedsettings.xml on the test file from the previous post.

  • The TrueHD track consistently starts with the audio at the ~+11 mark, left alone the offset will stay at the point. Skipping back 10 sec with the left button the audio jumps to the ~-6 mark. Also replicated on the Spears and Munsil AV sync sample with the same offsets.
  • The DD+ track, usually, starts at the ~+11 mark and then, without any input, it then drifts through +12,-12, -11 and then settles at ~-6 mark. With a single 10 sec backwards skip, it then typically doesn’t really change offset (sometimes changes to ~-4). When it doesn’t start at the ~+11 mark, the audio will start at the -6 mark.

Can someone else also try playing with the advancedsettings to see if the results can be replicated?

edit: tests from this post were on version 21.1.1-Omega_nightly_20241111

111

I hope you test and make logs without any user advanced tuning…

112

yes… That was just something I found interesting that I thought may be useful

edit: any any case, shouldn’t the advanced setting just provide a constant offset though?

113

I unpacked a SM1, S905X3 and tested your example. It’s in perfect sync, every time. So make a video with mobile to actually see/here the issue.
And make kodi.log in parallel.

114

Assume you want the video for the test without the advanced setting even though the results are more obvious with the advanced setting?

115

Without any custom settings. We are not here to solve issues caused by user configuration.

116

I get that and will do the test that way, but shouldn’t a misconfigured offset still be a constant offset? Am I misunderstanding what that option does?

117

I have no idea about this advanced setting and if it still apply when hardware decoders are used.

I only see the first beep after seek isn’t on +0 frame. But the second and following are again on frame 0.

1 Like
118

I just tested the above file on my setup and cannot see any out of sync issues, also not after seeking.

My setup is AM6B+ → Avidgram HDMI 4K/120 splitter → Denon AVR-X2800H → Philips 48OLED808 TV.

None of the audio tracks show any sync issues.

I do have one delay of 83 ms (2 frames @ 23.976) configured on the Denon but that’s just because of something quirky going on between the TV and the Denon. I need this delay for all other connected sources as well. My old TV did not need this, so I’m blaming the firmware on the new TV for this.

1 Like
119

Agree, I tested all files from reset9999,
All is in sync. No delay needed.
Tryed ff rew, paused, no issue.
Amb6+ > 8k hdmi splitter extractor> one go to the tv > one to the avr system.

1 Like
120

kodi-android.log (995.2 KB)
kodi-ce.log (6.3 MB)

Here is a log (kodi-ce.log) from testing with today’s nightly (I’m not sure where to obtain previous version but they are still out of sync regardless). I used Audio-delay-test-v5_23.976.mkv since it was easier for me to see the sync errors visually. At the start of playback it is ~ +1 oos. I did a seek forward and now it is in sync. Another seek forward, it is now ~ +3 oos. Then I paused/resumed, it is now ~ +1 oos. Another seek forward, it is now ~ -4 oos. And finally stop. (These numbers should be multiples of a 23.976fps frame time corresponding with the bars on the screen).

I also uploaded a log from Kodi running under Android (kodi-android.log) on the exact same equipment in the exact same configuration. Here, the video starts out of sync but self-corrects itself multiple times until it is finally in sync. I was hoping perhaps the Android log could provide some insight.

Setup is CE → Q990B Soundbar → LG CX

2 Likes
121

What app will do this? The test files look in sync to me, but when watching a movie or tv show with someone talking its obvious to me that it is out of sync.

122

Mine was in sync to begin with but seeking backwards and forwards a few times threw it out by between 1 and 3 frames.