[Tanzbaerli]

In fact, as I said previously, your org.xbmc.kodifoo21 build gives me perfect video and audio for everything (using IEC)!

So the question is what changes were made that would affect video playback?

Just to clearify:
In my report from above i speak from micro audio dropouts, i have not observed any problems with the the video with each build.
(but i did not give special attention to it)

[SoulReaver]

In fact, as I said previously, your org.xbmc.kodifoo21 build gives me perfect video and audio for everything (using IEC)!

So the question is what changes were made that would affect video playback?

Someone please correct me if I am wrong, but I believe the “official nightly build” actually made the changes or reverts on TrueHD IEC that reintroduced the video stuttering/frameskipping issue but fixed the dropouts so it’s a similar situation like it was in official 19.3 stable in that regard.

19.4 stable I believe then fixed the video issues but introduced random audio dropouts for TrueHD IEC and the latest fix from supertoto1977 has now fixed the dropouts problem by building on top of that I think.

Nice work and I can confirm that the supertoto1977 arm64 build for my Shield Pro 2019 also fixes all audio and video issues in TrueHD IEC for me as well.

I have tested three 2+ hour long 4K TrueHD Atmos Blurays so far and no issues found.

[Tanzbaerli]

Nice work and I can confirm that the supertoto1977 arm64 build for my Shield Pro 2019 also fixes all audio and video issues in TrueHD IEC for me as well.

Now 3 testers confirm that the Supermoto fix is "the best" and is running by all testers without problems.
(on the Shield devices 64 and 32 bit)
Is there a technical reason not to use his fix in the new Kodi20 nightly builds and later in the stable?

Is there a negative effect on other devices?

Great work Supermoto !

[Tanzbaerli]

Great work Supermoto !

Äh sorry ... Supertoto :-)

[fritsch]

Nice work and I can confirm that the supertoto1977 arm64 build for my Shield Pro 2019 also fixes all audio and video issues in TrueHD IEC for me as well.

Now 3 testers confirm that the Supermoto fix is "the best" and is running by all testers without problems.
(on the Shield devices 64 and 32 bit)
Is there a technical reason not to use his fix in the new Kodi20 nightly builds and later in the stable?

Is there a negative effect on other devices?

Great work Supermoto !

Technical reason: It's not correct. It returns the wrong delay (factor 2), which causes a fallback delay of 0 ms, in fact it produces stuff like "-170" or "-190" or even "3800 ms" over the whole time, the fallback code in Audio Engine adjusts this to "0ms". With this 0 ms, the buffers are faked so dry towards VideoPlayer that no adjustment at all happens and it tries as fast as it can to add new packages. This combined with low buffers of < 16 ms exactly produces this -> no A/V sync maintaining at all anymore. So it keeps it running, which is the reason you don't see an effect. If you carefully check the A/V sync, you will see that it slowly drifts. The reason for your micro stutters or for the short TrueHD outtage is, that exactly this drifting is corrected. And fixing this drift by either checking that the delay is properly returned or the vblank is not missing one is a solution.

There is one thing where the change does exactly the right thing: VideoPlayer now knows the real length of the TrueHD samples, here a div by two was missing. I also have seen that in the code and fixed it properly. For the other technical reasons (don't mix them with but, but, but it works for me reason) were already given in the github pull request.
Which is why I kindly asked in the github report to fix the root-cause and not just "stopping" the player to adjust A/V sync when it runs off too much.

See - another "non-fix" would be to adjust the threshold to 400 ms instead of 200 ms for Videoplayer to interfere ... but is this again a fix? No, it's again a workaround.

[Tanzbaerli]

Thank you that you have explained the technical background so that i can understand it!

I hope that you find a perfect solution but i even can life with your fix.
My micro stutters are very rare with your solution and they disturb only in load scenes.
(to do the correction in silent scenes is not possible? This would make the problem nearly unnoticed)

Its very annoying for us users that there are

• ​​​​​​​not much devices that support DTS or TRUE-HD Atmos
  
• that the few devices do not work perfectly
  

Thanks for your work and "mosty" perfect player!

[fritsch]

My micro stutters are very rare with your solution and they disturb only in load scenes.

Wait - are you saying, if there is a lot going on, e.g. action scenes - these "stutters" happen? Is this really correlated? Could you please check the video bitrate during that time? I honestly hope it's not some "throttleing" then, e.g. "we run smoothly, audio delay works perfectly, nvidia is clocking down the GPU / CPU" and on sudden action it does not come out of sleep mode - this would also explain why the other "workaround" works ... it keeps the CPU entirely busy :-). Not sure if you can see the temperature on the shield, but with Supertoto version, you should see the CPU temp going up :-) <- is this the case?

For TrueHD / DTS-HD:
It's supported for more than 10 years on basically every intel NUC. On Android, you are most likely correct - I have high hopes on API > 31 versions, as here the "normal" 2 channel IEC limitation was removed and we might see soonish more and cheaper devices which support it properly, see: https://developer.android.com/reference/...G_IEC61937
cite: "For devices whose SDK version is less than Build.VERSION_CODES.S, the channel mask of IEC61937 track must be CHANNEL_OUT_STEREO." Means starting with S - 8 channels should be fine for more devices ... nvidia is one of the few that allows the 8 since beginning, even though the Audiotrack standard tried otherwise ... Kodi tries to open "both" 8 and 2 and then provide DTS-HD-MA / TrueHD or nothing of that.

[Tanzbaerli]

My micro stutters are very rare with your solution and they disturb only in load scenes.

Wait - are you saying, if there is a lot going on, e.g. action scenes - these "stutters" happen? Is this really correlated? 
(....)

No, you misunderstood me.

This stutter happens always, just in load scenes you hear them immedeately (because the noisy surround action sound stops for a part of a second) and in silent scenes they are hardly recognizeable.
Therefore even i thought that they happen only on action scenes which is NOT true.

[Hitcher]

I think Tanzbaerli means 'loud' not 'load' but I think fritsch might be onto something nonetheless.

[jogal]

Sound Delay +0.2 seconds ... otherwise its not lip sync!

This "may" indicate you have Dolby processing Shield setting enabled.  Please confirm.

In any case, unless it is only that video file, it means that you have a broken setup.

[jogal]

EDIT2: Tested about 10 minutes of the 4K BluRay of Alita: Battle Angel. Dolby Vision triggers and works as expected. First time I watched it, there were frequent video stutters the entire 10 minutes

Please this is not "Dolby Vision testing thread". DV has merged very recently and still in "experimental state". Do not use DV video files to test TrueHD audio dropouts (or, if so, at least ignore the video issues).

It is known that there are issues to be investigated in DV (jerky playback at random time points) and probably some more changes in the code are necessary to make everything perfect.

We must be very scrupulous with the tests because it is easy to reach totally incorrect/unrelated conclusions.

[jogal]

Shield is not a very powerful device. It only allows you to play fluid video because it has graphic HW acceleration dedicated to it.

For everything to go well, you have to avoid anything that consumes CPU (or CPU spikes):

• Turn off Wifi if you use Ethernet
  
• Turn off BT pairing requests
  
• Turn off Kodi cache if you only play videos on LAN (NFS/SMB)
  
• Use default Kodi skin
  
• It is preferable to use NFS than SMB (NFS consumes less CPU)
  
• Turn off AI based upscaling
  
• Restart Shield from menu one time a week...
  
• ...
  

Do not do tests with the recently installed APK (first 2 minutes). The Android OS is doing background maintenance tasks (recreating cache, etc.) and there is simply an extra CPU consumption.

[Filmbuff]

Just a question, how do I turn off the cache in Kodi?

[Tanzbaerli]

I think Tanzbaerli means 'loud' not 'load' but I think fritsch might be onto something nonetheless.

Yes, sorry for my Eglish and the writing error!

[jogal]

Just a question, how do I turn off the cache in Kodi?

In advancedsettings.xml

xml:
  <cache>

    <buffermode>3</buffermode>

  </cache>

https://github.com/xbmc/xbmc/blob/5715cb....h#L21-L25