[wesk05]

And yeah - no need to test. I wrote the code for IEC - two months ago on the firmware you got a week ago. I know it is working :-)

Why is that 24-bit 96/192kHz Dolby TrueHD and even 24-bit 48kHz DTS-HD Master Audio passthrouhg are using AE_FMT_S16LE? Is this AudioTrack problem?

Log shows
DEBUG: CAESinkAUDIOTRACK::Initialize returned: m_sampleRate 192000; format:AE_FMT_S16LE; min_buffer_size 262400; m_frames 8200; m_frameSize 16; channels: 8

for audio stream:
Stream #0:5(jpn): Audio: truehd, 192000 Hz, 5.1(side), s32 (24 bit)

Dolby TrueHD (24/192kHz): http://pastebin.com/K5bEe9YS
DTS-HD Master Audio (24/48kHz): http://pastebin.com/fjCsC4Hv

[wrxtasy]

@Supernovasx: Yeah - nice to hear. v18 development also starts nicely. peak3d is currently porting Android and AMLogic ...so it won't get worse in the future :-)

Yes and peak3d has done some very good work with AMLogic's help for AML LibreELEC Kodi Krypton. AML Android users should get some nice bug fixes with Kodi v18 Leia

[fritsch]

And yeah - no need to test. I wrote the code for IEC - two months ago on the firmware you got a week ago. I know it is working :-)

Why is that 24-bit 96/192kHz Dolby TrueHD and even 24-bit 48kHz DTS-HD Master Audio passthrouhg are using AE_FMT_S16LE? Is this AudioTrack problem?

Log shows
DEBUG: CAESinkAUDIOTRACK::Initialize returned: m_sampleRate 192000; format:AE_FMT_S16LE; min_buffer_size 262400; m_frames 8200; m_frameSize 16; channels: 8

for audio stream:
Stream #0:5(jpn): Audio: truehd, 192000 Hz, 5.1(side), s32 (24 bit)

Dolby TrueHD (24/192kHz): http://pastebin.com/K5bEe9YS
DTS-HD Master Audio (24/48kHz): http://pastebin.com/fjCsC4Hv

oO.... Come on. We send the IEC frames in that format. Has nothing, absolutely nothing to do with the content it ships. It's passthrough, you forgot?

[wesk05]

oO.... Come on. We send the IEC frames in that format. Has nothing, absolutely nothing to do with the content it ships. It's passthrough, you forgot?

Well... what comes out of the HDMI port has messed up channel status bits (On LibreELEC - Intel also). It shows up as 16-bit with 768kHz sampling frequency. There are other Android boxes (eg. Zidoo X9S) that shows correct channel status bits. Messed up channels status bits can be a problem with AVRs that strictly follow them.

[Koying]

oO.... Come on. We send the IEC frames in that format. Has nothing, absolutely nothing to do with the content it ships. It's passthrough, you forgot?

Logging in K+ would need some tweaks, though.
Currently, we only see that AE_FMT_RAW is requested and short ints are returned (for IEC) and (if I read the code right) AE_FMT_RAW will be returned for droid RAW.

A tad confusing, and the PT subtype appears nowhere...

[fritsch]

That's right. I think I will print the android values. the AE_FMT_16 is what AE internally does. Also in passthrough context, this is just for the transport stream.

For completenes:

If one sees this in the log:

12:29:36.203 T:1560271136 DEBUG: AESinkAUDIOTrack: Using IEC PT mode: 13

Everything passthroughed will be IEC PT - as that one always has priority. Internally we handle it the AE way, e.g. we are asked with AE_FMT_RAW. The AE_FMT_16 is used to indicate PT back to AE. Yes - it's confusing. Will fix tonight.

Something like: Passthrough (RAW), Passthrough (IEC) in use. I will make the AE internals that confuse users a debug log statement.

[fritsch]

oO.... Come on. We send the IEC frames in that format. Has nothing, absolutely nothing to do with the content it ships. It's passthrough, you forgot?

Well... what comes out of the HDMI port has messed up channel status bits (On LibreELEC - Intel also). It shows up as 16-bit with 768kHz sampling frequency. There are other Android boxes (eg. Zidoo X9S) that shows correct channel status bits. Messed up channels status bits can be a problem with AVRs that strictly follow them.

Kodi's passthrough for IEC is the same on all platforms. So it should be the same everywhere. Kodi sends IEC TrueHD, DTS-HD within an IEC frame and 192 khz / 16 bit and 8 channels (remember channels is not really a standard in that regard, it's about bandwidth). We signal every dts-hd the same - so it might very well be an issue. Mind looking in the packer?

If you check the data sheet of the DP -> HDMI converter of the new nucs, you will see that it only supports 2 channels with 768 khz, aka 8 channels with 192 khz. But again, it's not a channel issue, but used for bandwidth. See: https://github.com/xbmc/xbmc/blob/master...C61937.cpp

[KornY05]

Hi, im on the AML S905X 6.01 version. Tryed the latest version and a few other "shitty" builds, but there is only Silence with DTS-Master-HD etc

The only build that works is that one: kodi-20170115-e495581-shitty-armeabi-v7a.apk

All newer Version are bringen only silence or rustle.

The Denon-AVR2313 supports Dolby TrueHD und DTS-HD, AC3 also...

In the Audio-Options i picked up DTS/AC3 capable and that works nice.
If i pick up DTS-HD and Master-HD also in the Audio-options there is no Sound again. Only with DTS and AC3 i get Sound and only on that Build.

[fritsch]

Shitty will only bring DTS/AC3 to your broken AML version. Until you receive a FW update - nothing we can do for you.

[KornY05]

ah ok, is there a newer version of the "shitty" build that will work and have "bugfixes" in it?

Version 115 works for DTS/AC3, Version 119 did not work or i made a mistake.

[fritsch]

Reboot the box several times. It's the very same code as before ... but as mentioned multiple times: PCM Hack is not reliable. If you got issues post a Debug Log or no one can help you.

[ssarava9]

Hi, im on the AML S905X 6.01 version. Tryed the latest version and a few other "shitty" builds, but there is only Silence with DTS-Master-HD etc

The only build that works is that one: kodi-20170115-e495581-shitty-armeabi-v7a.apk

All newer Version are bringen only silence or rustle.

The Denon-AVR2313 supports Dolby TrueHD und DTS-HD, AC3 also...

In the Audio-Options i picked up DTS/AC3 capable and that works nice.
If i pick up DTS-HD and Master-HD also in the Audio-options there is no Sound again. Only with DTS and AC3 i get Sound and only on that Build.

Disable DTS-HD and True HD capable receiver option in Kodi audio settings, this will solve DTS-HD source playback problem

[wesk05]

Mind looking in the packer?

If you check the data sheet of the DP -> HDMI converter of the new nucs, you will see that it only supports 2 channels with 768 khz, aka 8 channels with 192 khz. But again, it's not a channel issue, but used for bandwidth. See: https://github.com/xbmc/xbmc/blob/master...C61937.cpp

I understand what you are saying. As a matter of fact, the link rate for HBR audio passtrhough is actually 768kHz, but when you use HBR passthrough, you have to set bit 1 to non-pcm. May be it is not and that is why the analyzer detects it as 2 channel 768kHz. I will have to check again whether it is set to pcm or non-pcm.

Here is a comment from Anssi Hannula from several years ago:

- set $CHANCOUNT and $RATE as per below - rate 192000 and channels 2 for IEC958 rate 192 kHz (for e.g. 48 kHz E-AC-3, and DTS-HD when the IEC958 rate was set to 192000 in ffmpeg) - rate 192000 and channels 8 for IEC958 rate 768 kHz (for most TrueHD files, and for DTS-HD when the rate was set to 768000) - note that having the 0x02 bit (non-pcm) set in AES0 is mandatory when $CHANCOUNT is larger than 2, as ALSA uses it to determine whether to use HBR or not. The additional 0x04 (non-copyright) I use above is not mandatory, but is the alsa default so I kept it.

Anssi Hannula

https://lists.freedesktop.org/archives/p...09380.html

I only have very basic knowledge of C++ (actually all languages), but I did take a look at the code for the packer. I will check it against IEC 61937-1,3,5 and see whether there is anything out of norm. I did notice that only the preambles for Dolby are defined. I didn't see the ones for DTS and it also looked like Dolby preambles are being used for DTS?? (I could be interpreting the code incorrectly).

[fritsch]

Mind looking in the packer?

If you check the data sheet of the DP -> HDMI converter of the new nucs, you will see that it only supports 2 channels with 768 khz, aka 8 channels with 192 khz. But again, it's not a channel issue, but used for bandwidth. See: https://github.com/xbmc/xbmc/blob/master...C61937.cpp

I understand what you are saying. As a matter of fact, the link rate for HBR audio passtrhough is actually 768kHz, but when you use HBR passthrough, you have to set bit 1 to non-pcm. May be it is not and that is why the analyzer detects it as 2 channel 768kHz. I will have to check again whether it is set to pcm or non-pcm.

Here is a comment from Anssi Hannula from several years ago:

- set $CHANCOUNT and $RATE as per below - rate 192000 and channels 2 for IEC958 rate 192 kHz (for e.g. 48 kHz E-AC-3, and DTS-HD when the IEC958 rate was set to 192000 in ffmpeg) - rate 192000 and channels 8 for IEC958 rate 768 kHz (for most TrueHD files, and for DTS-HD when the rate was set to 768000) - note that having the 0x02 bit (non-pcm) set in AES0 is mandatory when $CHANCOUNT is larger than 2, as ALSA uses it to determine whether to use HBR or not. The additional 0x04 (non-copyright) I use above is not mandatory, but is the alsa default so I kept it.

Anssi Hannula

https://lists.freedesktop.org/archives/p...09380.html

I only have very basic knowledge of C++ (actually all languages), but I did take a look at the code for the packer. I will check it against IEC 61937-1,3,5 and see whether there is anything out of norm. I did notice that only the preambles for Dolby are defined. I didn't see the ones for DTS and it also looked like Dolby preambles are being used for DTS?? (I could be interpreting the code incorrectly).

That's what we do, see: https://github.com/xbmc/xbmc/blob/master...A.cpp#L491 - for Android we have no influence besides setting the IEC Format.

See, especially: https://github.com/xbmc/xbmc/blob/master...A.cpp#L494 (0x02 | 0x04 = 0x06) - basically what Anssi (who wrote that code) said.

[wesk05]

As mentioned earlier, the analyzer reported 2 channel 16-bit 768kHz with LibreELEC x86-64 also. The analyzer strictly adheres to standards. If it detects the channel status bit as PCM, it won't further decode the encoded audio. I have to say that I don't remember everything that I did yesterday. Let me do some more testing and see whether I can figure out what's going on.