Passthrough Changes
Audiotrack-Sink for Android was revisited the last days and made it API conform. That means, everyone gets what the official Android API supports:
Sie müssen registriert sein, um Links zu sehen.
Concerning passthrough that means:
< v21 API: nothing
v21, v22 API: AC3, EAC3 (broken on most firmware, please bug your vendor)
v23: AC3, EAC3, DTS, DTS-HD (if supported, not on the Nexus 5)
v24 (Android N): AC3, EAC3, DTS with the new IEC API, we miss hardware / software to implement dts-hd, truehd
On Nvidia Shield: AC3, EAC3, DTS, DTS-HD, TrueHD
For old AML devices (<= 5.0) I ported the AML specific API, dependend on this you will get: AC3, EAC3, DTS or even DTS-HD, TrueHD which I implemented last March with a core device by wetek. This does not (!) count for the broken release chinese boxes with pseudo Android 6.0 (see below).
Why was the old method of PT removed?
Starting with newer API there is a FLOAT mixer internally, which might harm your ears, as mixing is going on and that might produce a significant noise. We were warned by Android Audio staff to not use these hacks.
Whenever the first of you has Android N device (not on Nexus) available, please ping me - happy to fully implement DTS-HD, TrueHD for these.
Vendor firmware bugs
- Some Android TVs only support 384 kb/s AC3 and error out on 640 kb/s
- EAC3 7.1 is broken on all FireTV firmware. I suggest disabling EAC3 and use Dolby Transcoding _and_ speakers set to 2.0. It makes no sense to passthrough if you can output 6 or more PCM channels
Help my DTS stopped working - but it did in Jarvis - you broke my system - you are damn idiots, Team Kodi 111!!!111
If you have a broken firmware, download the shitty builds. They are named matching your firmware. Currently on this list are:
FireTV 1 and 2, Some prerelease AMLogic Android 6 versions that ship a broken, e.g. shitty FW, never released as final by AMLogic.
Current shitty version:
Sie müssen registriert sein, um Links zu sehen.
(Updated 17/03/9) - Handle with care, you are warned. This version can kill your ears as it fakes passthrough via PCM as Jarvis did.
For semi broken firmware, e.g. Android Sony TV, Philips TV, some others with AC3 640 issues:
PCM speakers: 2.0
Enable AC3
Enable AC3-Transcoding
and (!) Enable Sync Playback to Display. This is need to force transcoding even of native AC3 Input as that might be 640 kbit/s and the FW cannot use it.
My SPDIF output on the shield does not work anymore:
Yeah FW bug. Nvidia has just forgotten about their spdif users. The only workaround for this is the shitty build from above
What if I don't understand all of this?
The PCM-Hack does the following: PT audio in IEC mode is shipped in so called IEC frames. Those frames tell what they have in it. Those IEC frames are transmitted via a 16 bit format. They are using a certain bandwidth. E.g. DTS / AC3 are send via 48 khz (44.1 khz) and 2 channels. DTS-HD / TrueHD via 192 khz and 8 channels. Channels in that regard are only used to describe the bandwidth.
You can think of a IEC package like a birthday present. The very moment the receiver knows how to unpack these, it will succesfully unpack the DTS / AC3 / EAC3 ... in it and it will play well. Now there is a problem though. The very moment the postman that ships these IEC packages does not know if those packages can be e.g. combined with certain other packages (resampled) or pushed a little (set volume), which would be a problem for the inner content of these packages.
So the good case:
Android sees the data coming in as 16 bit wise shipped packages and does neither resample them and does not change the packages volume. If that is given - everything is fine and the AVR will successfully receiver the content of the packages. In order to do that. We tell Android: Ey Android - please set your volume to 100% to not touch anything, so that we can savely unpack the IEC packages later on.
But now something evil (might happen). Beginning with Android 5 - the AudioTrack (the postman sending audio packages) has a certain shelf where it might store the packages, trying to combine the packages with others, trying to alter the packages (resampling) to better fit in the current post-car. If this happens the non interpretable content of your package gets broken.
If this happens: you will hear plain noise on your AVR in full volume - this will kill your ears.
Therefore we changed that in kodi v17. We only ship the passtrhough audio stuff if there is a special, secure post-service, that e.g. tells us: Yes, I got it - i won't touch the packet content, I won't mix it - I will even block the post-car so long until all your packages are transmitted.
The "shitty" build reintroduces the Jarvis behaviour of sending PT audio. A sidenote: The so called PCM hack in Jarvis is even more dangerous as it is now in v17. As in Jarvis plain "zeros", e.g. packages with the packaging the receiver / AVR was not able to unpack properly, were sent. Therefore it's quite common in Jarvis that you get a seconf of noise on start and after stop by default.
Any questions left?
Version 17.1 builds to be found here:
Notsoshitty:
Sie müssen registriert sein, um Links zu sehen.
Shitty:
Sie müssen registriert sein, um Links zu sehen.