[fritsch]

We support IEC passthrough and RAW passthrough, too.

But this fucked up S912 version don't support either, they just "tell to do so" via firmware. In reality nothing besides the pcm hack works.

[wrxtasy]

Amlogic already implemented the pass-through changes in their source code but manufacturers are too lazy to get it and would rather release new devices to get payment a second time from customers.

Bit of a correction here, there are numerous Bug fixes for AML Android devices in the currently available AML Nougat 7.x codebase.
But dirt cheap S9xx sellers are either completely clueless, lack the skills or don't give a fuck about patching current AML Marshmallow 6.x Firmware on already purchased devices.

There is no money to be made in doing that sort of thing. As already stated, cheap Android Sellers would rather spend their time selling you a new buggy Android device.
It is all about moving Boxes out the door as quick as possible. Not fixing Firmware to use standard Android API's and be Krypton compatible.

This is dirt cheap Android media player marketing 101 - and its been going on for quite a while now.

[anpaza]

Could you explain what this means?

01:23:25.275 T:18446744073433516336 DEBUG: Firmware implements DTS RAW

does it just mean that ENCODING_DTS is (theoretically) supported in API >=23? Or KODI doesn't use that? Why it's mentioned in log, then?

[fritsch]

I think you don't get it. I try a last time:

This broken device tells: I can do DTS_RAW, I can, I can, I can. But it can't! - they have just plenty forgotten to implement it properly. When Android 6 ran, they sold it and you bought it.

[anpaza]

If ENCODING_IEC61937 is supported too, it is preferred over all other encodings?

I know a man with same device, who says that DTS works for him with KODI 17.1 from play market. My guess is that in this Android 6.0.1 it is implemented in some (incorrect) way and AVR gets some (incorrect) stream (wrong framing?), but his AVR can sort out the data from the stream and mine (and most others) can't. Is that possible?

[fritsch]

Yes.
No.

[kraka40]

Ok .. so been away for a week and changed settings on Kodi 17.1 as recommended earlier in thread and I am now getting DD 5.1 for recorded and live TV (for the most part). Thank you!

Two open issues though and I was hoping to get an answer to them:

1 - i've seen others raise a concern with DD transcoding only occurring once DD played with other engine. For instance, I go into Kodi play a video ABC and I get 2-channel PCM. I exit Kodi, play any DD+ movie from Amazon (FTV), stop movie, go back to Kodi and play same video ABC and get DD/5.1 transcoded correctly. Is this a known bug?

2 - Original question still stands, why do I need to select 2 as my speaker configuration to get the AC3 transcoding option. Seems counterintuitive, is there a reason for this, or just how the logic in the interface works out per some legacy algorithms.

Thanks again!

[fritsch]

Ac3 virtual format, transmitted via 2 pcm channels, decoded to 5.1 by avr.
If 5.1 pcm possible directly, no single need for inferior ac3 encoding.

[anpaza]

The transcoded AC3 bitrate is always 384 kbits? I've read that was limited due to bugs in some weird sony TVs?

[fritsch]

The transcoded AC3 bitrate is always 384 kbits? I've read that was limited due to bugs in some weird sony TVs?

Yes (on Android only: 640 kbit/s on all other OS including 25$ RPi). AC3 is lossy anyways. It makes zero sense to reencode a decoded signal back to AC3 just to see Dolby on the AVR display. But for those shitty boxes with just ARC output there is no alternative as they are limited to 2 PCM channels.

[kraka40]

So is this correct?

FTV1 and FTV2 passthrough works, but due to concerns with Live feeds which requires finer tune controls of the active audio buffer the signal must be locally handled (decoded). Recorded content can be passed through without concern providing DD and DDP on the receiver. DTS is not supported by FTV.

Since FTV only supports a 2 channel PCM output signal due to crappy implementation of MediaCodec in FTV2 and non-standard implementation in FTV1, the signal needs to be transcoded back to an AC3 signal which is transmitted as a 2 channel signal, hence the requirement for a 2 speaker configuration, which in this case represents the PCM decoding capabilities of the Android hardware, not the receiver and speaker configuration.

Am I close?

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

Yes (on Android only: 640 kbit/s on all other OS including 25$ RPi). AC3 is lossy anyways. It makes zero sense to reencode a decoded signal back to AC3 just to see Dolby on the AVR display. But for those shitty boxes with just ARC output there is no alternative as they are limited to 2 PCM channels.

[anpaza]

The transcoded AC3 bitrate is always 384 kbits? I've read that was limited due to bugs in some weird sony TVs?

Yes (on Android only: 640 kbit/s on all other OS including 25$ RPi). AC3 is lossy anyways. It makes zero sense to reencode a decoded signal back to AC3 just to see Dolby on the AVR display. But for those shitty boxes with just ARC output there is no alternative as they are limited to 2 PCM channels.

Wouldn't it make sense to make that a user setting? E.g. instead of a ON/OFF switch, just let the user pick one of "disabled", "384 kbits/s", "448 kbits/s", "640 kbits/s".
I use the optical S/PDIF to connect to my AVR and, as far as I understand, that does not support LPCM, only HDMI supports it, right?
My AVR is 10-year old and doesn't have HDMI in, so without re-encoding to AC3 I would be always limited to stereo.
But I don't see why I should enjoy 384kbit/s just because some existing device doesn't support 640.
Letting the user choose it would allow to balance between various limits, not only sony tvs but cpu load, firmware quirks etc...

By the way, I think the datalink speed limit of 48kHz/16 bit stereo is 1536 kbits/s? Why not use this bitrate, am I missing something?

[Martijn]

Would it make sense for manufacturers to not make crap firmware?

[anpaza]

The world is full of bugs, you can't change that.
But I have no single piece of hardware labeled sony in my house... so why I get 384 kbits/s then? Am I responsible for the whole sorrow of this world?

[Draega]

If you don't like the way this free software that is coded by volunteers in there free time is made then feel free to modify the code and make your own version. It is open source. If not then there are other options out there. Feel free to use one of them.