Kodi Community Forum

Hey folks,

I recently had the idea to upgrade my equipment from a Pioneer VSX-923 to a Denon X2800H and also spent a pair of Atmos reflection speakers. I was not unhappy with the Pioneer but I wanted Atmos support paired with 4k60p support. With the Pioneer, I used an additional audio extractor to have 4k60p at my TV and TrueHD/Atmos at the Pioneer. That worked, but is always a workaround. All in all, I should have now a rather standard setup which is probably installed many times somewhere else. My Kodi box is Linux-based on a ASrock J4105 (Celeron J4105 with UHD Graphics 600).

With the Denon I noticed right from the start issues with Atmos tracks (every Atmos track). Every couple of seconds and especially in motion scenes, little drops / cuts / breaks are audible, which is basically impossible to listen to. As I changed the equipment, the reason could have been everything but I was able to trace down a little.

• The issue does not occur on other sourround tracks like DD 5.1
  
• The issue does not occur with a dedicated UHD Bluray Player connected to the Denon
  
• The issue does not occur if I connect the Kodi box directly to the TV and use eARC back to the Denon
  
• The issue does not occur if I use my old audio extractor to send video to the TV and audio to the Denon
  
• I do not see any entries in the kodi debug log in the moment the audio issues occur
  

So, I could narrow it down to an issue with the Kodi box and the refresh rate setting. I do have Settings / Player / Video / Adjust display refresh set to "On start / stop", because it get rids of video stuttering caused by pulldown. Disabling this, solves the audio issues in Atmos tracks. So I tried defaulting the display refresh rate to 24p and surprise, this also results in the Atmos issues again. But I don't want to go with 60p default as it will result in video stuttering issues.

Back at the Denon I go to Setup / Video / 4K/8K Signal Format and change the format from "Enhanced" to "Standard". This limits the capabilities to 60p 4:2:0, but this actually works. Refresh rate is adjusted and no Atmos sound issues anymore. For now, this is the best compromise but it is obviously a limitation and a workaround.

The question is: Why is the combination of 24p and the Denon not working properly in my case? I would assume this to be a rather standard situation.

Appreciate your input!

Chris

(2023-02-26, 17:52)Hitcher Wrote: [ -> ]Release - Audio Passthrough IEC - TrueHD fix/workaround - Testing build

Thanks,  I saw that before, but it seems to be Android-related only. I do have x86 here.

In the meantime, I did some more tests with the external hardware UHD Player. I was able to confgure it simiiar to Kodi to see if it results in the same audio issues, i.e. enforcing 24p playback and comparable settings. I was not able to force the error though. But I noticed that Kodi always sends with RGB 12 Bit color depth. Can this be changed for testing purposes, e.g. to 10 or 8 Bit?

Sorry, missed that you were on Linux.

This did solve my problem with the atmos stuttering problem I had on linux based installations, set Denon to Standard mode instead of "Enhanced".
Atmos did work flawlessly on windows with "Enhanced" activated on Denon, so this must be some strange behaviour on linux based system.

but thank you for this info. I have the Denon AVR-A110. With this info, I can finaly go back to use linux again..

Debug Log added: https://paste.kodi.tv/tadederoqi.kodi

That log does not show a single audio issue - BUT - vnsi that constantly seems to update the EPG data. Please stop vnsi entirely, restart kodi and play the TrueHD as sample as long until you hear an issue.

Thanks @fritsch for coming back on this.

(2023-02-28, 07:53)fritsch Wrote: [ -> ]That log does not show a single audio issue -

I know, that's why it's even harder to narrow it down. During the time of the log, the issue occured 3 times. During my analysis I "tailed" the debug log in live mode to directly see if something happens during the audio glitches, but there is nothing.

(2023-02-28, 07:53)fritsch Wrote: [ -> ]BUT - vnsi that constantly seems to update the EPG data. Please stop vnsi entirely, restart kodi and play the TrueHD as sample as long until you hear an issue.

Yes and it did it before the last 5 years. The one thing that changed is the AVR. For me this seems to be some kind of format / negotation issue between Kodi and the AVR. But I also disabled it now for testing purposes and the issue remains. Additional debug log here.

Thanks!

If you open the debug osd after some minutes. Do you see any skips / drops in the OSD?

As years have passed - this J4105 - was this the LSPCON? E.g. not really a HDMI 2.0 device, but a Display port with some more or less proprietary intel lspcon behind it?
If yes - plug in the HDMI 1.4 port and check if the error is gone?

(2023-02-28, 20:52)fritsch Wrote: [ -> ]If you open the debug osd after some minutes. Do you see any skips / drops in the OSD?

0 skips, 0 drops

 

(2023-02-28, 21:55)fritsch Wrote: [ -> ]As years have passed - this J4105 - was this the LSPCON? E.g. not really a HDMI 2.0 device, but a Display port with some more or less proprietary intel lspcon behind it?
If yes - plug in the HDMI 1.4 port and check if the error is gone?

That was with the predecessor architecture. The J4105 has native HDMI 2.0 support. I used the opportunity to do a BIOS upgrade which was surprisingly available but that did not have any effect either on the issue.

Just to be on the safe side, I also reverted to a clean kodi config.

Jep, there is basically nothing I can do for you :-(. There is no error indication, no clock adjustment and not a single skip / drop. So from kodi POV the issue is not existent.

(2023-02-28, 23:14)fritsch Wrote: [ -> ]Jep, there is basically nothing I can do for you :-(. There is no error indication, no clock adjustment and not a single skip / drop. So from kodi POV the issue is not existent.

Not sure if ActiveAESink logs anything if input queue runs dry and it has to output silence or pause. Later if that leads to showing the same video frame twice to get in sync again, it is again not logged or shown on the debug screen. I might be wrong becuase it's been a while but it should be worth checking.

I thought about that as well - but as it works perfectly fine in 60 hz ... I don't think that this is an issue. A/V clock adjusts we would see, when discon happens. And as audio clock and video clock are separate but only synced via PTS to each other, I would not assume that suddenly audio runs dry in 24 hz mode, while it does not in 60 hz. But yeah - just assumptions.

While this print should happen as we need to toggle between: SYNC_ADJUST and SYNC_MUTE (which would cause the silences  during playback, e.g. the bursts) and SYNC_INSYNC: https://github.com/xbmc/xbmc/blob/master....cpp#L2527 - so it needed to switch the state, right?

But might be also this one: https://github.com/xbmc/xbmc/blob/master...k.cpp#L561 ... when no new data arrives ... it drains and goes to idle. So logging here if I got it right would be a good idea. I would only expect that transition on end of playback or when pausing a stream.