[Nuklear92]

Hmmm I'm seeing some "less friendly" conversations going on in the rework PR

I hope you guys are still on the same track

Yup, I been keeping an eye 👁️ as well. Hopefully everything that’s being discussed ends up getting fixed. Even if it takes two different PRs.

[Cinephile]

By the way, how many seconds or minutes do you actually record for the audio component debug log in order for it to show anything unusual. I’m not sure if it’s something just like playing an audio track that’s DTS-HD for a few seconds or so I have to watch an entire episode or movie? Lol

You'll most likely need to watch that episode until you hear the audio dropout again. It will most likely show up in the log as an ErrorAdjust right after a ~90 ms jump, since we already know that the Shield has this problem.

Basically, the Shield will occasionally have a spike of around 90 ms, so then Kodi will do an ErrorAdjust to sync up the audio and video. This usually results in a video stutter -- or in your case, an audio dropout. That's where the new setting  maxpassthroughoffsyncduration = 90 comes in. This basically tells Kodi to ignore that 90 ms jump, so ErrorAdjust isn't triggered and everything still looks smooth. This comes with a downside however, the A/V sync will be slightly off. That's where the delay = -75 setting comes in. I found that setting the global delay to -75 effectively cancels out the downside of using maxpassthroughoffsyncduration set to 90.

Hopefully I got the technical details right, otherwise I'm sure @fritsch will correct me. Either way, I highly recommend you try my advancedsettings.xml changes afterwards, as they specifically target fixing the Nvidia Shield issue.

Personally, I prefer to set the global delay in Kodi settings as that makes switching values a breeze, should there be a need for it down the track.

[faust1103]

So which is the most up to date version of Kodi that we should use with the advancesettings.xml ?

[fritsch]

Hmmm I'm seeing some "less friendly" conversations going on in the rework PR

I hope you guys are still on the same track

Yup, I been keeping an eye 👁️ as well. Hopefully everything that’s being discussed ends up getting fixed. Even if it takes two different PRs.

Here: https://jenkins.kodi.tv/view/Android/job...64-v8a.apk  - latest outcome. Curious on your feedback.

Hehe - friendly discussing. Sometimes it's not so easy to look in other people's mind -> therefore keep calm and relax :-)

[fritsch]

Hmmm I'm seeing some "less friendly" conversations going on in the rework PR

I hope you guys are still on the same track

If you want to achieve a technical solution, discussion is needed. Some are more argument driven others get a bit heated. I am with kodi since way more than 10 years ... many fights fought. Not many were worth it when looking back. So, all good -> we quasi-agreed now on something. Let's see what you testing reveals. This is again solely and purely focussed on TrueHD. There is not impact on other code.

[Nuklear92]

Hmmm I'm seeing some "less friendly" conversations going on in the rework PR

I hope you guys are still on the same track

Yup, I been keeping an eye 👁️ as well. Hopefully everything that’s being discussed ends up getting fixed. Even if it takes two different PRs.

Here: https://jenkins.kodi.tv/view/Android/job...64-v8a.apk  - latest outcome. Curious on your feedback.

Hehe - friendly discussing. Sometimes it's not so easy to look in other people's mind -> therefore keep calm and relax :-)

Is that build for DTS-HD?

Edit: oh! Nvm that’s the new build with the rework TrueHD fixes. So, could you summarize what you guys ended up doing and what this build brings compared to all the previous ones? 🤔

Nvm either, I just read the description in GH. Damn! You guys should also do that rework too with DTS-HD so any possible Audio Dropouts that had been happening are gone too, Lol. 😅

Anyways, I’ll give it a spin I might not notice any difference in TrueHD in my end as it has been performing pretty good. But if this keeps the same pace or even better that’s a plus! Even before testing this, I hope you guys ended up fixing this for good as you wanted from the root. That way you can move on to improving other things even related to the audio in general that you might have discovered throughout the process of fixing this. 👍

[fritsch]

Yup, I been keeping an eye 👁️ as well. Hopefully everything that’s being discussed ends up getting fixed. Even if it takes two different PRs.

Here: https://jenkins.kodi.tv/view/Android/job...64-v8a.apk  - latest outcome. Curious on your feedback.

Hehe - friendly discussing. Sometimes it's not so easy to look in other people's mind -> therefore keep calm and relax :-)

Is that build for DTS-HD?

Edit: oh! Nvm that’s the new build with the rework TrueHD fixes. So, could you summarize what you guys ended up doing and what this build brings compared to all the previous ones? 🤔

Nvm either, I just read the description in GH. Damn! You guys should also do that rework too with DTS-HD so any possible Audio Dropouts that had been happening are gone too, Lol. 😅

Anyways, I’ll give it a spin I might not notice any difference in TrueHD in my end as it has been performing pretty good. But if this keeps the same pace or even better that’s a plus! Even before testing this, I hope you guys ended up fixing this for good as you wanted from the root. That way you can move on to improving other things even related to the audio in general that you might have discovered throughout the process of fixing this. 👍

I did not see your log, yet. DTS-HD works entirely different, all the glibber path that TrueHD introduces (fluctuating size of packages, payload != sinkpayload, etc.) is not there ... so when you have an issue with DTS-HD, you most likely also have one with ordinary DTS. As the packages are same size.
If you have your logs together, feel free to open a new Forum thread.

What I currently really know that is broken - cause it never worked - is DD+ 7.1 Passthrough. Here some higher bitrate files fail to pack ... no matter if android or linux or windows ... but that is not related to the work here.

[Nuklear92]

Here: https://jenkins.kodi.tv/view/Android/job...64-v8a.apk  - latest outcome. Curious on your feedback.

Hehe - friendly discussing. Sometimes it's not so easy to look in other people's mind -> therefore keep calm and relax :-)

Is that build for DTS-HD?

Edit: oh! Nvm that’s the new build with the rework TrueHD fixes. So, could you summarize what you guys ended up doing and what this build brings compared to all the previous ones? 🤔

Nvm either, I just read the description in GH. Damn! You guys should also do that rework too with DTS-HD so any possible Audio Dropouts that had been happening are gone too, Lol. 😅

Anyways, I’ll give it a spin I might not notice any difference in TrueHD in my end as it has been performing pretty good. But if this keeps the same pace or even better that’s a plus! Even before testing this, I hope you guys ended up fixing this for good as you wanted from the root. That way you can move on to improving other things even related to the audio in general that you might have discovered throughout the process of fixing this. 👍

I did not see your log, yet. DTS-HD works entirely different, all the glibber path that TrueHD introduces (fluctuating size of packages, payload != sinkpayload, etc.) is not there ... so when you have an issue with DTS-HD, you most likely also have one with ordinary DTS. As the packages are same size.
If you have your logs together, feel free to open a new Forum thread.

What I currently really know that is broken - cause it never worked - is DD+ 7.1 Passthrough. Here some higher bitrate files fail to pack ... no matter if android or linux or windows ... but that is not related to the work here.

Oh, I understand. I tried to compile a debug log but they’re massive. I recorded like 30 seconds but I believe that shouldn’t tell anything as there wasn’t any dropouts, stutters which doesn’t even happen in the first place with any DTS, DTS-HD track I’ve played. Only very random audio dropouts different occasions. What I would like to know is, if I should watch and record a debug log as you say but watching an entire movie or tv show episode? But the log would be extremely big and there won’t be a place for me to share it to you. 🤷‍♂️

Btw, that DD+ 7.1 issue. I never was aware of that not working, perhaps as I’ve always played the typical 5.1 DDP audio stuff and never seemed to have issues thanks for the heads up. Is that another project you have to fix as well? 🤔

[MrMagic]

Here: https://jenkins.kodi.tv/view/Android/job...64-v8a.apk  - latest outcome. Curious on your feedback.

Did some testing, but not an entire movie yet. I set the advanced setting to the default of 10 and no delay. Sync seems fine on all samples.

I played race_test.mkv and the first 20 mins of Alita Battle Angel. Did not notice any audio dropouts or video stutter. The debug log does show ErrorAdjust entries though:

https://paste.kodi.tv/ezetubeyeq.kodi

[fritsch]

2023-02-11 14:31:10.015 T:20647   debug <general>: ------ Window Deinit (DialogBusy.xml) ------
2023-02-11 14:31:10.055 T:20658   debug <general>: ActiveAE::SyncStream - average error of -144.602341, start adjusting
2023-02-11 14:31:10.203 T:20658   debug <general>: ActiveAE::SyncStream - average error -19.992350 below threshold of 30.000000
2023-02-11 14:31:11.090 T:21012    info <general>: CDVDVideoCodecFFmpeg::CDropControl: calculated diff time: 41708
2023-02-11 14:31:11.231 T:21029   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:83117.683843, adjusted:83117.683843
2023-02-11 14:31:12.281 T:21029   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-35069.730258, adjusted:-35069.730258

All good, this first one. That is how we want it: Audio Clock and Video Clock are adjusted during SyncStream.

The rest actually has lots of erroradjusts ...

2023-02-11 14:38:49.567 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-27308.203906, adjusted:-41708.333333
2023-02-11 14:38:50.591 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:20659.691409, adjusted:41708.333333
2023-02-11 14:38:55.711 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-44803.423140, adjusted:-41708.333333
2023-02-11 14:38:56.734 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:22878.252503, adjusted:41708.333333
2023-02-11 14:38:59.807 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-27888.390375, adjusted:-41708.333333
2023-02-11 14:39:00.830 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:20048.573883, adjusted:41708.333333
2023-02-11 14:39:18.241 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-30277.313667, adjusted:-41708.333333
2023-02-11 14:39:19.265 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:22798.585308, adjusted:41708.333333
2023-02-11 14:40:04.319 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-30312.023583, adjusted:-41708.333333
2023-02-11 14:40:06.366 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:21064.008860, adjusted:41708.333333
2023-02-11 14:40:12.522 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-33989.275124, adjusted:-41708.333333
2023-02-11 14:40:14.558 T:22152   debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:27516.253122, adjusted:41708.333333

41.078 == 1000 / 23.976 (24p).

Here you see that the error introduced was more than a frame time and the clock was adjusted. You should have definitely seen stutter at this point. Also to the others: Please carefully check if suddenly those increase heavily by value. For TrueHD the delay adjust is now constantly active as the error is always calculated no matter the waterlevel. So A/V sync should be great - but let's see the impact on the erroradjust ... it might be too hard now.

The delay there is not a lot it moves within one frame mostly. So A/V sync should be perfect ... but maybe it's adjusted too often now ...

with a maxallowoffduration of 30 or 40 ms - it should look much better.

[MrMagic]

Here you see that the error introduced was more than a frame time and the clock was adjusted. You should have definitely seen stutter at this point.

These time stamps correspond to the playing of race_test.mkv I believe. That video is quite frantic so I could have missed the stutters. I will test it again with both 10 and 40 ms maxallowoffduration and see what happens.

EDIT: Interesting part is that during the 20 mins I played Alita Battle Angel, there were only a few ErrorAdjusts at the start and then nothing until the end.

EDIT 2:

Did two runs with race_test.mkv. First one with 10 ms which has a lot of ErrorAdjusts same as before. Second one with 40 ms and only one ErrorAdjust.

Honestly I still could not see video stutter in either run. I hope others can verify.

10 ms run: https://paste.kodi.tv/jasoxinegu.kodi
40 ms run: https://paste.kodi.tv/ovogegoles.kodi

[fritsch]

Nice - thanks for the feedback.

[Draconix]

Here: https://jenkins.kodi.tv/view/Android/job...64-v8a.apk  - latest outcome. Curious on your feedback.

Is this the next version of the "aerework" builds (with a name change), or is it something completely different?
 

Honestly I still could not see video stutter in either run. I hope others can verify.

10 ms run: jasoxinegu.kodi (paste)
40 ms run: ovogegoles.kodi (paste)

There are so many ErrorAdjusts in your 10 ms logs, there almost certainly are micro-stutters happening there. I think it's likely that you probably just aren't sensitive to micro-stutters so you aren't noticing them. Other people (like me) are more sensitive to stutters and notice them easily, and it's very distracting.

Though it's interesting that 40 ms advancedsetting is enough to cancel out the ErrorAdjusts in your case. Does that suggest that the ErrorAdjust corrections were actually still within 1 frame (~41 ms), which is maybe why you didn't see any stutters?

[fritsch]

The above build is kodi's master from tomorrow ... int includes aerework to a large degree but has additional changes to not manage TrueHD via the waterlevel logic.

[Nuklear92]

The above build is kodi's master from tomorrow ... int includes aerework to a large degree but has additional changes to not manage TrueHD via the waterlevel logic.

Tested the build with the first 10 minutes of Black Adam and couldn’t tell the difference from the nightly build fixes previous to these. Meaning, for me it’s pretty solid. No stutters or audio dropouts. Of course I’ll keep testing more with daily usage. 👍