• 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 27
Android Fire TV Cube 3 & HD Audio Passthrough w/24p Support (Workaround Builds)
#46
It is easy to be confused. That's packed "internally", we use the 8x2x192 khz as a transport stream only, while inside is digital data in IEC frames which - contains 24 bit audio samples, but encoded in a way so that the AVR receives the container and decodes it. The difference to RAW is, that in RAW we give the "real payload" to Android and here Android packs it into IEC frames. And to make it even more funny: We pack that in a way that the "PCM equivalent" frame <-> samplerate correlation equals the size inside of the payload of the container. So that sink delay (data needs time to be read / processed) equals the real TrueHD / DTS-HD-MA length.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#47
Device came - and in short: All is working fine with the version I posted one page back, if you don't seek.

Tested:
TrueHD, DTS-HD-MA -> work perfectly for seek and sync

DTS, AC3, EAC3 -> work as long as you don't seek. Seems flush is not properly working. Will find out.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#48
(2023-02-13, 07:27)fritsch Wrote: It is easy to be confused. That's packed "internally", we use the 8x2x192 khz as a transport stream only, while inside is digital data in IEC frames which - contains 24 bit audio samples, but encoded in a way so that the AVR receives the container and decodes it. The difference to RAW is, that in RAW we give the "real payload" to Android and here Android packs it into IEC frames. And to make it even more funny: We pack that in a way that the "PCM equivalent" frame <-> samplerate correlation equals the size inside of the payload of the container. So that sink delay (data needs time to be read / processed) equals the real TrueHD / DTS-HD-MA length.

Thanks for the in depth explanation, I always thought Kodi only sent a max of 16bit audio quality. As most of the time it’s what’s shown whenever you view basic logs without debug option being enabled. 😅
Reply
#49
(2023-02-13, 17:28)fritsch Wrote: Device came - and in short: All is working fine with the version I posted one page back, if you don't seek.

Tested:
TrueHD, DTS-HD-MA -> work perfectly for seek and sync

DTS, AC3, EAC3 -> work as long as you don't seek. Seems flush is not properly working. Will find out.
bandwidth question pertaining to the playback

which method have you chosen to connect your cube to your network? Built-in Ethernet, WiFi or External USB Ethernet Dongle?
Reply
#50
I bought an USB2.0 Gigabit Adapter as hdmkv suggested. I used an ASIX chipset, disable Wireless entirely - I did not even test it. I used the amazon basic one - will do iperf tests later on ... so far so good.

First I was astonished that everything worked okayish, but then I tried to "Seek" and here it seems that Audiotrack flush is not working and the data basically stays on the sink ... filling. Will debug this tonight to find out.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#51
right on, im fully aware of the different speeds attainable via the different methods and their impact on playback.
you could keep on topic just leaving your connection method as a note for anyone trying to duplicate results if that suits you.
Reply
#52
The issues that currently happen on the Cube are quite clear ... kodi's log pictures it already quite fine ... issues coming from buffering look differently.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#53
Thanks much for your work on this already @fritsch. Will follow progress on resolving the seek issue. I assume this doesn't affect chapter up/down skips as I didn't notice an issue w/it.
Reply
#54
Affected are the 2 channel IEC formats (DTS, EAC3, AC3).
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#55
The good news: It's not the Flush.
The bad news: It's actually really a firmware bug with IEC mode ... the sink just does not move for a long time, then "eats the buffer" away below .... and returns low delay values :-( ... not good.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#56
So: https://jenkins.kodi.tv/view/Android/job...bi-v7a.apk - this is the wooden hammer. There is - for now - no correlation that I see between us adding data, it really seems that the sink hw is not moving anymore - why unknown.

This version kindly asks AE to reopen if error goes above 600 ms. That happens multiple times during start with IEC ... so let's stay tuned if they fix it, until then ... have fun.

Hint: It can take three seconds after seek till audio is back in sync, sadly.

Good: Only DTS, AC3, EAC3 is affected. You can also just disable those three in kodi's settings. TrueHD and DTS-HD-MA work perfectly.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#57
thank you fritsch
Reply
#58
This is more than a great stop-gap until Amazon hopefully addresses the issue. Stupid question: I assume we should stay on this latest build you shared vs. upgrading to any nightly (that won't have the "wooden hammer")?
Reply
#59
Let me build a nexus version with that - so that you can enjoy things quite okayish - until amazon updates their firmware - if they ever do :-)
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#60
Awesome, thank you again.
Reply
  • 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 27

Logout Mark Read Team Forum Stats Members Help
Fire TV Cube 3 & HD Audio Passthrough w/24p Support (Workaround Builds)0