• 1
  • 50
  • 51
  • 52(current)
  • 53
  • 54
  • 70
Android Passthrough Changes with v17
Smile
and then my patch would be rejected.
I know this trick Big Grin

That's why I'm first trying to make sure that would be a useful option.
I was suggesting that you make a version for yourself.

The shitty and not so shitty builds were fritsch being a nice guy and trying to help out the Sony TV users and others who were having audio issues.

With so many combinations of android hardware and avr's and wonky firmware you well at least I don't ever expect the kodi team to be able to get all permutations working 100%. I'm just greatful it works as well as it does.
Patch already exist: https://github.com/koying/SPMC/commit/7e...cdc5fc4fe7
I.e. Use the "Resample quality" setting, with <= Medium -> 384k and anything higher -> 640k.

Now I'm pretty sure the patch would be refused, indeed, unless it is limited to Android BUT does not use ifdef Wink
(2017-04-17, 03:16)Koying Wrote: Patch already exist: https://github.com/koying/SPMC/commit/7e...cdc5fc4fe7
I.e. Use the "Resample quality" setting, with <= Medium -> 384k and anything higher -> 640k.

Now I'm pretty sure the patch would be refused, indeed, unless it is limited to Android BUT does not use ifdef Wink

Workarounds only needed for android should stay on android only and not clutter other perfectly working fine platforms. Remember we use 640 kbit/s AC3 since more than 5 years, even on the shittiest Pentium 4 onboard spdif outputs. Then the broken Android firmwares came along and suddenly to workaround that shitty firmware (pcm hack was also a workaround) will clutter generic code, while all those workarounds are obsolete the time 7.0 will be standard. Workarounding documented broken firmware will stop generic development. If we would not have made public that RAW implementation was the biggest bullshit ever and forced on IEC mode - nothing would have happened on that ecosystem at all. So in my eyes going for a short workaround will introduce yet another mess - I think you remember the AML, stagefright, mediacodec times and the AML sink inside the AudioTrack still there.


I suggest something else:
For v17 there was this cmake change introduced for android only. The relevant setting could be added to this file only and the setting could be used on android only.

E.g. do it here: https://github.com/xbmc/xbmc/commit/2a13...417358dR23 - no other platform would be harmed and android would get the relevant setting.

Edit: Remember: Those TVs evennot cannot output "normal" standard AC3 that are 640 kbit/s too - so another workaround will ALSO be needed, that is "Sync Playback to Display" and 2.0 speakers to also decode and reencode 640 kbit/s AC3 -> 5.1 PCM -> 5.1 AC3 384 kbit/s ... enough reasons to push on vendors to fix their firmware.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
(2017-04-17, 11:01)fritsch Wrote: For v17 there was this cmake change introduced for android only. The relevant setting could be added to this file only and the setting could be used on android only.

Yep. I hate this "thing" as you know (I still fail to see in what having self-changing build code via cmake is better that via ifdef, just to it is much harder to read), but it's indeed the acceptable common ground.
Christian Fetzer is on his way preparing something that makes these "more general", after that one is in - adding that setting for $port only is much easier.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Hello guys (thumbs up for KODI).
I've read somewhere that Android resamples all audio files to 48kHz. Is it true?
It is unbelievable we are in 2017 and we still discuss those topics (not kodi fault of course).
Isn't the passthrough option the "easiest" one to implement at the end?
So many lazy/incompetent manufacturers spoiled the whole market.
I am still searching for a list of Android Boxes can play passthrough stereo 44.1 / 48 / 96kHz at least (multichannel PCM/DTSHD/TrueHD are nice to have though) without success.
Thanks to this thread AML s912 is definitely disqualified (unless a miracle happens).
(2016-09-05, 20:37)fritsch Wrote: 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: http://mirrors.kodi.tv/test-builds/android/arm/ (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.

I take it I should be looking for a build with firetv in the name?
No. With shitty in name, see first post, please.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
AMLOGIC has implemented the KODI 17 Passthrough support for android M and Android N.
We back-ported AUDIO_FORMAT_IEC61937 support on Android M.
We added that at the end of last year.
Yes and now it is up to sellers to implement those changes in update MM Firmware. Trouble is the cheap Ship & Forget guys cannot be bothered to do so, they would rather sell you shiny new buggy Nougat devices now.

(2017-05-08, 22:21)vkostas Wrote: Hello guys (thumbs up for KODI).
I've read somewhere that Android resamples all audio files to 48kHz. Is it true?
It is unbelievable we are in 2017 and we still discuss those topics (not kodi fault of course).
Isn't the passthrough option the "easiest" one to implement at the end?
So many lazy/incompetent manufacturers spoiled the whole market.
I am still searching for a list of Android Boxes can play passthrough stereo 44.1 / 48 / 96kHz at least (multichannel PCM/DTSHD/TrueHD are nice to have though) without success.
Thanks to this thread AML s912 is definitely disqualified (unless a miracle happens).

It should be those "bad-brands" that you should be disqualifying, not the AML S912,
the chip itself is fully OK to run Kodi 17 nicely, with proper firmware implementation/updates.
Agreed, and that is why I only recommend the MINIX U9 as that is the only S912 that has both IEC61937 Audio support and fixes the 1080p colorspace issue that all other AML S912's still have. Smile

Not sure if MINIX has Multichannel PCM Audio support tho.

(2017-05-11, 20:36)fritsch Wrote: No. With shitty in name, see first post, please.

Are Shitty builds only 32 bit? Guess it doesn't matter much?

I take it Nvidia have not remembered their SPDIF users yet :p
(2017-03-16, 08:50)Koying Wrote: Shield is a reference device. Every format works there as far as Kodi is concerned.
The DTS issue is with mediatek based TV's, Sony and Philips.

If you have a passthrough issue on shield, 95% chance it's a misconfiguration or a h/w issue.

I just purchased a Sony CT-790 soundbar to accompany my X830 android tv. Quickly enabled DTS etc from the settings menu. All went fine until I played a movie, as it turns out there was no image and no sound. When I disabled passthrough both the image and sound resumed. After a bit of Googling I ended up here.

If I understand it correctly the issue did not exist on Android 5.x with Kodi 16? I am really not looking forward to buying a shield just for sound compatibility (yet ANOTHER remote). I really love that the TV just has Kodi integrated, that was the main selling point for me. Does it help if I uninstall 17.1 and go back to 16.1 via sideloading?
  • 1
  • 50
  • 51
  • 52(current)
  • 53
  • 54
  • 70

Logout Mark Read Team Forum Stats Members Help
Passthrough Changes with v178