Audio changes for kodi 21 Omega

Audio changes for kodi 21 Omega - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Android (https://forum.kodi.tv/forumdisplay.php?fid=164)
+---- Thread: Audio changes for kodi 21 Omega (/showthread.php?tid=376161)

Pages: 1 2

Audio changes for kodi 21 Omega - fritsch - 2024-02-04

During the development of version 21 a huge load of fixes were done, find a small documentation below, categorized as follows:
- Transparently (no need to do anything)
- More ore less FW bug workarounds (user has to explicitely enable them)
- Known issues that won't be fixed.
- Changes related to Audio

Transparently:
- TrueHD delay fixes were done and tested for month in a dedicated thread. Here especially Shield shortcomings of the audio driver implementation which caused fluctuating delay due to large software period size in their Audio-Hal resulted in skip issues in the renderer. An automated delay learner checks that - on every box - and adjusts that during the first view seconds: https://github.com/xbmc/xbmc/pull/22870 - you can additionally control this offset by specifying an advancedsetting value, if you feel the need, choose a value between 10 and 100:

Code:
<advancedsettings>

  <audio>

    <maxpassthroughoffsyncduration>80</maxpassthroughoffsyncduration>

  </audio>

</advancedsettings>

- Channel Mapping. It was found out, that basically every box we tested is unable to properly do 3.0, 3.1 or 4.0, 5.0 or 6.0. Kodi opened that channel configuration perfectly, the Audiotrack also took it nicely, but sadly under the hood only 2.0 stereo was output. As a workaround kodi opens 2.0 for 2 channels and 5.1 for more than 2 channels but less than 6 channels, and 7.1 for more than 6 channels: https://github.com/xbmc/xbmc/pull/24554

More or less FW bug workarounds (action is needed, if you have an affected box):
- The FireTV Cube 3rd Gen was the first box who had a broken delay firmware on startup. That means it consumed up to 2 seconds audio without playing a single bit, then just to reopened its internal Sink, throwing seconds of audio away without telling the clients. Result: Huge out of sync on those devices. Fun-Fact: Other devices using same Amlogic BSP are affected as well. A workaround for tracking that issue inside kodi was implemented, but sadly this broke "semi-broken" devices like the Ugoos box, which would also open with 160 ms buffer, but consume up to 480 ms of data before moving, but afterwards having a more or less proper audio-sync. Result: We could not enable this workaround by default, cause of breaking other boxes. This had to be changed from "enabled by default" to opt-in short before v21 release.
If you have a FireTV Cube 3rd Gen and your audio is really "seconds off" when doing IEC Passthrough, you will need to have the following advancedsettings.xml for v21 stable in place: https://github.com/xbmc/xbmc/pull/24597

Code:
<advancedsettings>

<audio>

<superviseaudiodelay>true</superviseaudiodelay>

</audio>

</advancedsettings>

- Multi-channel lossless output. Again many Android firmwares, among others "old FireTV Cube 2nd" and "old FireTV 4K Max" have an issue outputting multi-channel PCM content in higher precission than 16 bit, while other boxes (Shield) and Firetv 4K Max 2nd Gen or FireTV Cube 3rd Gen, among others can nicely do that. As always in Android world, it might change daily with a vendor or firmware update, which is the reason whitelists are no solution, it changes faster than we can build. As having it by default would break a huge load of boxes, I tried in v19 iirc, but you can enable that via and advancedsetting: https://github.com/xbmc/xbmc/pull/24553

Code:
<advancedsettings>

  <audio>

    <allowmultichannelfloat>true</allowmultichannelfloat>

  </audio>

</advancedsettings>

See also the wiki: https://kodi.wiki/view/Advancedsettings.xml#audio

- Known issues that won't be fixed:
RAW Passthrough was most likely the worst idea ever that Android folks had to implement. Reason for this: They don't provide any functionality to fill the sink (delay problems) or even move data out of the sink when seeking (same issue). So in comparison to IEC there are no pause bursts possible to be generated and the implementations to cope with that heavily differ. Some boxes seem to create pause bursts if you pause the Audiotrack sink, other boxes don't do that and will silently fail the moment you do. During kodi development cycle we had enabled sometimes one or the other, while people heavily complained that now their (Sony) TV is broken but worked before. While Shield users said: Works now great, was broken before. Out of that reason every change for RAW passthrough was reverted - in short: we won't waste any energy here anymore. If it works for you, use it - if your firmware cannot seek: sorry for that, works as designed: https://github.com/xbmc/xbmc/pull/22945

- Changes related to Audio:
Refreshrate switching workarounds were incorporated affecting behaviour of kodi in two positive ways:
- When switching during startup, remember that decision and properly enumerate audio afterwards
- On resume, when e.g. kodi was moved in background, AVR went off, rescan for audio devices
- See: https://github.com/xbmc/xbmc/pull/24484

This thread documents changes only, it is not meant as "my stream buffers support channel".

RE: Audio changes for upcoming v21 - MrMagic - 2024-02-04

(2024-02-04, 08:25)fritsch Wrote: An automated delay learner checks that - on every box - and adjusts that during the first view seconds

Might be worth mentioning that you can also force a specific value here instead of relying on the "learner":

Code:
<advancedsettings>

  <audio>

    <maxpassthroughoffsyncduration>nnn</maxpassthroughoffsyncduration>

  </audio>

</advancedsettings>

Where nnn can be a value between 10 and 100, with a default of 10 I believe?

RE: Audio changes for upcoming v21 - fritsch - 2024-02-04

(2024-02-04, 12:43)MrMagic Wrote:
(2024-02-04, 08:25)fritsch Wrote: An automated delay learner checks that - on every box - and adjusts that during the first view seconds

Might be worth mentioning that you can also force a specific value here instead of relying on the "learner":

Code:
<advancedsettings> <audio> <maxpassthroughoffsyncduration>nnn</maxpassthroughoffsyncduration> </audio> </advancedsettings>

Where nnn can be a value between 10 and 100, with a default of 10 I believe?

Thanks - added, good point.

RE: Audio changes for upcoming v21 - Cinephile - 2024-02-05

Great write-up, thanks.

On that note, why would you choose <maxpassthroughoffsyncduration>nnn</maxpassthroughoffsyncduration> over the automated delay learner? Are there key benefits of one over the other?

RE: Audio changes for upcoming v21 - fritsch - 2024-02-05

(2024-02-05, 02:49)Cinephile Wrote: Great write-up, thanks.

On that note, why would you choose <maxpassthroughoffsyncduration>nnn</maxpassthroughoffsyncduration> over the automated delay learner? Are there key benefits of one over the other?

The learner finds systematic issues, e.g. it constantly reads the measured offset for the first 30 seconds and does not take action during that time, besides it would be higher than 100 ms. There are some setups or better let's say conditions that combine this systematic issue with "on the fly" issues, e.g. a byte from network was late, a struggeling scene coming on top, moving this calculated offset by some ms. Therefore those users set it to a very high value by themselves to not run into this condition. This calculation really only makes sense, if there is a systematic reason for short term spikes, like on the Shield, where every third audio package is blocking for a long time, while packet 1 and 2 make it basically without blocking, means: on average it is kind of okay, but Audio Engine was designed for perfect sync and not for some audio hal laziness ;-). 99% of the Shield devices with that issue are fine with that algorithm out of the box.

So in short: No need to set it manually, besides your setup shows a combination of further delay issues with this described issue. On especially MrMagic's setup the Shield decided to peak out of nowhere durning playback towards a higher value than it appeared during learning phase, causing few stutters, therefore he sets it to a value nearly the maximum.

RE: Audio changes for upcoming v21 - yaqwa - 2024-02-09

Since KODi 21.2 Beta I have the problem that my movies with Dolby Digital Plus that I have on the hard disk no longer play any sound, it is only about movies with Dolby Digital Plus and if I turn off the switch on Dolby Digital Plus capable receivers then it works again and I have a sound. This has only happened since I switched from KODi 20 to KODi 21.2

RE: Audio changes for upcoming v21 - izprtxqkft - 2024-02-09

(2024-02-09, 16:57)yaqwa Wrote: Since KODi 21.2 Beta I have the problem that my movies with Dolby Digital Plus that I have on the hard disk no longer play any sound, it is only about movies with Dolby Digital Plus and if I turn off the switch on Dolby Digital Plus capable receivers then it works again and I have a sound. This has only happened since I switched from KODi 20 to KODi 21.2

this thread is outlining changes regarding "audio sync", it's not a target for all audio issues

start a New Thread outlining your issue and provide a Debug Log

RE: Audio changes for upcoming v21 - Amjak - 2024-02-16

Ugoos Am8 user here
First of all passthrough is working with kodi iec packer.
But with true-HD audio is out of sync. The picture comes before the audio. Maybe around 300 ms. but can't say exactly. All other sound formats are perfectly synced

RE: Audio changes for upcoming v21 - fritsch - 2024-02-16

This is not a bugtracker. But yeah - expected for the Udoo. It's sync is totally off, but the user who caused a patch to be reverted for everyone did not admit that some weeks ago, while I told him from the Debug Log ... Nothing I can do ...

i find that funny ... cause I exactly told YOU (now that I checked it again), that your devices opens with 160 ms and consumes more than 480 ms without moving. This is exactly your delay. You wanted it that way ;-) you got it.

See: https://forum.kodi.tv/showthread.php?tid=376090&pid=3181789#pid3181789

Complain to Ugoos. They need to properly report their delay, else it's nuts.

RE: Audio changes for upcoming v21 - cridemichel - 2024-02-18

Hi,
the learner activates for 30 seconds also after pausing the movie?

best C.

RE: Audio changes for upcoming v21 - fritsch - 2024-02-18

(2024-02-18, 14:43)cridemichel Wrote: Hi,
the learner activates for 30 seconds also after pausing the movie?

best C.

It would not make too much sense, to start from beginning. Reason: It mitigates a "systematic" error. It is not a "sync improvement" or something. As describe above. The code is always run, when an Audio stream is constructed. It does not control the sync value at all, but the "max offset" it allows. The Shield, when opened with 160 ms buffer works like Time to Add (TTA):
TTA(0) = 1 ms;
TTA(1) = 2 ms;
TTA(2) = 85 ms;
TTA(3) = 5 ms;

and so on.
As you see on average: 93 / 4 ~ period length. Which means again, that on this "window" the sync is perfectly fine, but the window of unknown is shortly quite high (85 ms in this example). That's what the algorithm detects. It won't magically make a broken delay working, it can only work if on average everything is fine, again on Average: All men in Germany are on average 1.8m high ... but, but, but, my friend is 2m ..

RE: Audio changes for upcoming v21 - cridemichel - 2024-02-18

(2024-02-18, 19:40)fritsch Wrote:
(2024-02-18, 14:43)cridemichel Wrote: Hi,
the learner activates for 30 seconds also after pausing the movie?

best C.

It would not make too much sense, to start from beginning. Reason: It mitigates a "systematic" error. It is not a "sync improvement" or something. As describe above. The code is always run, when an Audio stream is constructed. It does not control the sync value at all, but the "max offset" it allows. The Shield, when opened with 160 ms buffer works like Time to Add (TTA):
TTA(0) = 1 ms;
TTA(1) = 2 ms;
TTA(2) = 85 ms;
TTA(3) = 5 ms;

and so on.
As you see on average: 93 / 4 ~ period length. Which means again, that on this "window" the sync is perfectly fine, but the window of unknown is shortly quite high (85 ms in this example). That's what the algorithm detects. It won't magically make a broken delay working, it can only work if on average everything is fine, again on Average: All men in Germany are on average 1.8m high ... but, but, but, my friend is 2m ..

thank you

RE: Audio changes for upcoming v21 - robbie599 - 2024-02-20

The workaround for when 2.0 stereo is output but 5.1 is required is not working in my situation – everything plays in 2.0 stereo.
Grateful for any help.

My setup is:

Device: Firestick 4K (latest version 2nd Gen, Android 11)
Kodi: 21 Beta 3
Kodi System settings:
Audio output device: AudioTrack (IEC), Kodi IEC packer
Number of channels: 5.1
Output configuration: Best match
Play GUI sounds: Never
Allow passthrough: Yes
Passthrough output device: AudioTrack (IEC), Kodi IEC packer
Dolby Digital (AC3) capable receiver: Yes
Dolby Digital Plus (E-AC3) capable receiver: No
DTS capable receiver: No
TrueHD capable receiver: No
DTS-HD capable receiver: No
- use DTS core: No

My log is at https://paste.kodi.tv/agaxuyowaq.kodi
Thanks.

RE: Audio changes for upcoming v21 - fritsch - 2024-02-20

This is not a bug tracker ... but your settings are wrong. Dolby Transcoding is only available if PCM Speakers are set to 2.0, see also the wiki.

RE: Audio changes for upcoming v21 - robbie599 - 2024-02-21

Thanks frische
Sorry if I posted this in the wrong section, but the Wiki guidance on this is a bit vague, ie: “if you are uncertain whether it is a bug, start in the Forum”.

I presume you are referring to the Wiki at https://kodi.wiki/view/Settings/System/Audio and that I should change “Number of channels” in Kodi System settings, from 5.1 to 2.0 (or even 2.1).
I’ve tried both, and it did not make any difference: the output is still 2.1

I’ve also experimented by changing my
a) Firestick 4K audio setting from “Best Match” to “PCM”
b) amp setting from “DEC.AUTO” (automatically switching between DTS, Dolby Digital, and PCM) to “DEC.PCM” (PCM signals are given priority)

Perhaps the problem is down to a quirk with either the Firestick 4K - or my amp, which is now getting rather long in the tooth.

Thanks anyway for your time.