[Martijn]

Please start reading.

[Supernovasx]

Please start reading.

Ive done a lot of reading but there is so much information.... I understand this is not a Kodi problem but Sony? If it is can I go back to v16??

[kinggo]

You can. But in reality, v16 isn't any better for me. It is until PCM hack breaks and kills my ears and that happens quite a lot. Your best bet is to use build that transcode everything to 384kbps AC3. The only problem then is that you don't have any sound with 640kbps AC3.

[fritsch]

I can make another build for you with 384 AC3 and also live tv fixed. And post if here if someone wants to have that.

[fritsch]

Here: http://jenkins.kodi.tv/job/Android-ARM/10575/ it's called goodpatched and contains: 384 AC3 by default and a preliminary fix (that fernet and I did) to show that LiveTV also works with mediacodec. That fixed the reopening issue, but is too intrusive for final v17. I think better v17 won't get for you :-)

Edit: Krypton based of course: http://mirrors.kodi.tv/test-builds/andro...bi-v7a.apk (wait until the mirror syncs).

[Supernovasx]

Here: http://jenkins.kodi.tv/job/Android-ARM/10575/ it's called goodpatched and contains: 384 AC3 by default and a preliminary fix (that fernet and I did) to show that LiveTV also works with mediacodec. That fixed the reopening issue, but is too intrusive for final v17. I think better v17 won't get for you :-)

Edit: Krypton based of course: http://mirrors.kodi.tv/test-builds/andro...bi-v7a.apk (wait until the mirror syncs).

Hi Fritsch,

Thanks for the trouble! I've installed the Krypton based APK file but still no DTS, Only DD5.1...

[fritsch]

I won't try again ... DTS is supported starting with API 23 or Android 6: https://developer.android.com/reference/...CODING_DTS

What worked with Jarvis was: "Hey Audiotrack, this is 16 bit Audio, in full volume, please don't touch it, cause we tunnel something in it, that the AVR might accept as DTS" ...

[Wegel]

Thanks for the feedback. But - to be honest - it does not help me at all. It just shows the buggy firmware for the Sony device.

Kodi will officially stop supporting XBR65X850C. As everything that is NOT working is not caused by kodi, but by their broken firmware. The images I provided were no solution but technically show the shortcoming of the implemented firmware by bypassing their implementation using a golden hammer.

Fair enough. Would it be possible to point me to a diff/commit of the modification you made for your build to work? That way, I can make sure there's at least a working patch somewhere, and maybe a custom, non-official build (just like you did), to support the Sony X850C. Thanks!

[fritsch]

No problem: https://github.com/fritsch/xbmc/commits/goodpatched
Evil PCM hack for firetv users that sold their brain and hearing for 40 dollars: https://github.com/fritsch/xbmc/commits/firetv

[Wegel]

No problem: https://github.com/fritsch/xbmc/commits/goodpatched

Thanks.

This is basically it (in xbmc/cores/AudioEngine/Sinks/AESinkAUDIOTRACK.cpp)? >

Code:

if (g_advancedSettings.forcepcmpassthrough)
    {
      CLog::Log(LOGWARNING, "You are using PCM passthrough - you were warned!");
      CJNIAudioFormat::ENCODING_IEC61937 = CJNIAudioFormat::ENCODING_PCM_16BIT;
    }

What are the downsides of not letting the OS know that what we're actually sending is *not* PCM? I mean, I know that philosophically it would be better to use the provided API to set things up; but personally, I've never had any problems with passthrough using Jarvis with my X850C (well, E-AC3 isn't working, but haven't really try to diagnose/fix yet), although I've heard that you can get static noise when the AVR doesn't properly recognize the stream and tries to actually play it as PCM; that would make sense, I guess.

[fritsch]

Why not just read the posts above yours? And see what happens?

Downsides:
if volume is applied, it's applied like it is PCM data, cause it does not know -> bscrrrscssscch noise
if android mixes (e.g. notifications coming through) -> brrrrsssssccchhhh
As there is no proper opening of the sink and internal buffer might be flushed or not (we only control AudioTrack not the hw) -> brsrscscshcsch noise on the start
If internal mixing is done with Float, no one knows how the mapping of the data happens to output sink.
Especially with TVs using their remote to alter the volume (100% volume on a TV - scary) - it will cause heavy, heavy issues.

It has zero to do with philosopy. It's about directly harming the listener at any time. So, please read through the posts in here, see my links to affected users and conclude.

[fritsch]

I have something for you to try: Please use a standard Krypton rc3 release and play this file (turn down the speakers, please, but keep Android's volume to 100%): https://mega.nz/#!VFVUxKSB!ew58jmrxe6OzD...npatdoNK8g

Now, when you hear the DTS sound (yeah, you will wonder why the AVR displays DTS suddenly, while you don't have it in your settings), press the vol down key. This sample includes "tunneled" DTS data and tells itself it would be PCM. Just that you can verify and see why we cannot tolerate the evil hack.

[Wegel]

Why not just read the posts above yours? And see what happens?

Because, same as you, I like to be efficient and not spend my time doing something useless. Reading 15 pages of posts, 90% of which are probably irrevelant to my somewhat precise question, isn't efficient. Proving my point:

Downsides:
if volume is applied, it's applied like it is PCM data, cause it does not know -> bscrrrscssscch noise
if android mixes (e.g. notifications coming through) -> brrrrsssssccchhhh
As there is no proper opening of the sink and internal buffer might be flushed or not (we only control AudioTrack not the hw) -> brsrscscshcsch noise on the start
If internal mixing is done with Float, no one knows how the mapping of the data happens to output sink.
Especially with TVs using their remote to alter the volume (100% volume on a TV - scary) - it will cause heavy, heavy issues.

It has zero to do with philosopy. It's about directly harming the listener at any time. So, please read through the posts in here, see my links to affected users and conclude.

THAT is an efficient summary. Thanks a lot for providing it, much appreciated. I now understand why informing the OS is important.

I'll try to code/find the smallest possible example proving (or disproving) that the X850C firmware is broken regarding v23 DTS and AC3 passthrough.

I have something for you to try: Please use a standard Krypton rc3 release and play this file (turn down the speakers, please, but keep Android's volume to 100%): https://mega.nz/#!VFVUxKSB!ew58jmrxe6OzD...npatdoNK8g

Now, when you hear the DTS sound (yeah, you will wonder why the AVR displays DTS suddenly, while you don't have it in your settings), press the vol down key. This sample includes "tunneled" DTS data and tells itself it would be PCM. Just that you can verify and see why we cannot tolerate the evil hack.

I can imagine what happens, but yes, I'll try it for good measure. Thanks again.

[Supernovasx]

I won't try again ... DTS is supported starting with API 23 or Android 6: https://developer.android.com/reference/...CODING_DTS

What worked with Jarvis was: "Hey Audiotrack, this is 16 bit Audio, in full volume, please don't touch it, cause we tunnel something in it, that the AVR might accept as DTS" ...

Fritsch, thanks for your trouble. For now I will just go back to Jarvis. I don't mind only using DD5.1 but I have quite some movies that only have DTS and DTS-HD and I cannot watch a movie with only PCM sound haha...

It's sad because Krypton looks really cool and fresh.. I would have loved to use it.

Let's hope our friends at sony update soon....

[fritsch]

Just set pcm channels to 2.0 and enable Dolby / AC3 Transcoding and all those DTS / DTS-HD will come out as AC3 ...