I made some tests last week but was way to busy to report them here afterwards.
TL;DR: I think Kodi <latency> setting is buggy and that explains why I can’t get the config I want. So, this has nothing to do with Portisch latest patches in the nightlies.
Digging through https://kodi.wiki/view/Advancedsettings.xml for something else, I realized that the <latency></latency> settings are part of Kodi! I thought it was a patch from Portisch himself. Well, now I know that he added the resolution, width and height attributes but that’s not the point here
Seeing that, I booted my LibreELEC NUC to test the same media, just of course, using a forced display of 1080 and SDR because of hardware limitations.
I’ve watched my test samples so many times now that I know them really well! To my big surprise, I now notice a slight delay on LibreELEC too because using the per file “Audio delay” Kodi popup and setting “Ahead by 167” feels way more natural now. I really don’t know how I didn’t noticed that before
So I did as with CoreELEC and used advancedsettings.xml to set a default like this
<latency>
<delay>167</delay>
</latency>
and… this does not “work”! I still need to set “Delayed by 167” with Kodi popup!
So the “bug” is already in Kodi and all the tests I did with CoreELEC trying different combinations couldn’t possibly work as nothing in CE is altering the Kodi behavior in that regard.
I also tried using the refresh tags and various combinations according to the Kodi wiki doc but nothing gave a satisfactory result.
Conclusion: Portisch, nothing is wrong with your patches bringing the “resolution”, “width” and “height” attributes! This is not where to search the root cause of the “latency” settings in Kodi for them to not be applied properly.
I have always (well, for many years) - found the audio sync noticeably better when using non-passthrough audio, and I know that one of the main Kodi video devs from way back (FernetMenta) always advised using non-passthrough (i.e. Kodi decoded) audio for best sync.
Even these relatively humble machines (e.g. Odroid N2) - have no issue with the load of decoding up to (at least?) 7.1 audio in any of the channel based formats (TrueHD or whatever) and passing that to my amp as Multi-In PCM. And my amp in turn can do all it’s processing on that incoming too, so I don’t think there’s really any disadvantage to this…perhaps there is some format that loses something this way, but I certainly can’t hear that, and to me that’s much less of a real issue than wandering drunk audio sync…
I changed to this years ago and all such sync issues really just disappeared…before that it was a regular bug bear with all sorts of Kodi players/versions.
(As per below, object audio (Atmos etc) is of course different and I don’t currently use that)
I think there is definitely something wrong with the latency calculation. Portisch says the default latency is calculated as defined here. If I have just this one advancedsettings.xml configuration:
then I think it applies to 23.976Hz sources just fine as seen when checking the debug info. However, I decided to check with a 25Hz and 59Hz file and now their latencies are negative, which shouldn’t be possible with the default latency calculation and with nothing in the advancedsettings.xml affecting those refresh rates.
Additionally, if I add another block for 25Hz specifically in advancedsettings.xml, the resulting latencies in the player debug info are not correct. And also, the latency for a 59Hz video changed again.
As for toggling passthrough, there’s an issue where if I toggle it off, I get no sound. However the file has multiple audio tracks, some of which are non-passthrough so I can observe the difference by switching tracks. And once again, with no advancedsettings.xml, non-passthrough audio is always in sync.
@bossanova808 Yeah, it would be fine but with object-based audio formats, it would be ideal to get passthrough working well.
Your config is strange to me because on my case, the delay must be positive and according to the calculation is exactly 166.67 or 167 if one wants a round number.
Also, in my case, <refresh resolution="2160"> or <delay>167</delay> alone as a default value both work for UHD/2160 content but not for HD/1080 content.
As shown in my previous post, trying to set anything regarding HD/1080 does not work, neither in CoreELEC nor in LibreELEC (x86). The bug is in Kodi itself it seems.
Indeed - I definitely was talking about channel based audio formats.
I have not gone to an Atmos etc. level system (and am unlikely to for some time as my lounge room doesn’t really accommodate this sort of thing, nor do I really feel the lack of it TBH…maybe one day when we move/build a house!).
slight off topic
A few months back I was in a demo cinema setup using big Barco projectors, multi loudspeakers fully Atmos compatible and all the bells and whistles. Even though everything was properly setup and calibrated, I wasn’t that impressed with the projected image quality. I own a OLED and I’m really into perfect picture quality rather than immersive image size. But, what took the cake was the sound system! I have a decent 5.1 setup but in that demo, I really felt what ceiling speakers bring to the audio immersion! Like you, my lounge room does not really accommodate, especially for side speakers but I’m really trying to find a solution to add ceiling speakers End of off topic
Sorry for being oftopic but, as far as I can see, I can’t send private messages here.
Considering the work you did on different formats I wanted to ask you a question. Since you’re familiar with the audio portion of the code maybe you know the answer. Would it theoretically be possible to differentiate passthrough settings for Dolby Plus and Dolby Plus with Atmos? Decoding the first and passing through the second, for obvious reasons.
Thanks if you will answer!
EDIT: unfortunately I doubt it, since you’re probably relying on Kodi’s FFMPEG implementation, which is still unable to differentiate between E-AC3 and E-AC3 with Atmos. Hope to be wrong.
Damn! I missed the informative part, you’re right!
BTW, I’ve done some quick tests on my LibreELEC x86 and bingo, using passthrough introduces a delay which does not exist otherwise. Disabling passthrough makes everything work, HD or UHD (displayed as 1080 SDR tone mapped due to hardware limitations) without any delay anywhere.
One theory I have is that passthrough does not take into account the frame buffer count. I’m not sure whether or not it’s just a coincidence that I needed to adjust my latency by -125.125ms (i.e. 3 frames at 23.976Hz) to get it in sync. Still, I need to test with the other refresh rates as well.
The issue remains that setting this delay negatively impacts non-passthrough audio.
Also btw, can you test whether having multiple refresh blocks does not work? It seems to only take one of the values and applies it globally regardless of refresh rate but I have to do more testing later.
I already did that, on CoreELEC though, described in Post #296 and Post #297 and yes, every test seems to indicate that only one block is taken into account but, in my case, only the 2160 block. As said in those posts, I even tried to change the order of the blocks.
