Posts by KOPRajs

I've played with the CPU settings a little more because running both CPU clusters on full speed all the time is not a feasible option for the H96 MAX box (because of the bad thermal design).

I'm getting the best results with setting like this:

Basically I turned the RK3399 big.LITTLE CPU into a simple dual-core Cortex-A72 SMP CPU by limiting the LITTLE cluster to a powersave state and telling the scheduler not to use it. "Isn't it ironic", turning half the CPU off actually makes the LibreELEC run faster?

So I've tested it and I can confirm that the audio "clicks / pops" get significantly reduced by setting the governor to performance. But they are not completely gone, they just seem to occur a lot less and they are also less noticable (only in quiet parts).

It seems it is related to the current CPU speed:

Low speed (powersave governor) -> more audio "drops" and bigger "gaps".

High speed (performance governor) -> less audio "drops" and smaller "gaps".

Looks like a buffer underrun issue to me.

Also it seems that the common atribute of the affected audio streams is that they are all 32-bit (like the AAC 32-bit from the YouTube sample above) which means they need a bigger buffer than a common 16-bit audio.

EDIT: I've tested it on the current official image with the rockchip-4.4 kernel but it seems that the problem affects all RK3399 images.

I've already moved from MX2 as my daily driver but I'm considering one last update when I got some spare time. Not sure if it is going to be based on LE 9.2 or LE 9.0 though.

Hi,

just to keep the thread updated.

I've updated to the latest LibreELEC-RK3399.arm-9.1.501-rockpro64.img.gz and I've also tested the mainline image from May 2019. Unfortunately both seems to have the same 2 problems:

1. The overall audio quality is bad (feels like low resampling quality or low output sampling frequency). I can tell the difference in the output quality even when playing simple [email protected] compared to the old Amlogic box.

2. The tiny cracking in some videos (e.g. YouTube).

My current quest is to find out whether these problems are specific to all Rockchip devices or only to RK3399 based devices or even only to the H96 MAX box. Also any indication whether the first problem is a hardware limitation or a software problem (possibly in the HDMI driver?) would be helpful.

It would also be helpful to compare the HDMI output to the S/PDIF but unfortunately the S/PDIF currently doesn't work on either of the images (in the current "stable" it almost works but the audio drops in and out and in the mainline image it doesn't work at all).

Kwiboo Can you elaborate a little on how the Kodi audio pipeline works? Is the RKMPP framework involved when playing plain audio file?

Hi there,

I've recently swapped my old Amlogic MX2 (Meson 6 based) box for a Rockchip RK3399 based box and I've noticed a significant loss in HDMI audio output quality. The box is connected to a SONY HDTV and the output is set to HDMI audio with 2.0 channels. Digital passthrough is disabled. I'm using the official RK3399 image (8.90.015) with Linux 4.4 and RKMPP framework.

I can't say the sound is not working, it plays almost fine and some people probably wouldn't recognize anything is wrong, but since I've got a decent 2.0 audio system connected to the TV I can definitely say the audio clarity is much worse than it is with the old Amlogic box. It is almost like the output sample rate is limited or resample quality is set to low. Sometimes I can also hear a tiny cracking like when you play a vinyl record

Anyone experiencing similar behaviour on a Rockchip device?

Kwiboo Can you confirm such behaviour? Could this be a hardware limitation or is it going to improve with the mainline support?

Thank you.

H96 MAX (4 GB version) with unmodified rk3399-rockpro64.dtb:

Linux kernel boots: OK

Kodi starts: OK

Ethernet: OK

HDMI CEC: OK

HDMI audio: OK

OpenGL ES 3.2 HW acceleration: OK

MPEG-2 HW decoding: Not tested as there are no PVR addons

So far so good

Unfortunately I've seen similar behaviour before. The NAND on my first box failed back in OpenELEC days and actually building a custom OE image which could use external SD card instead of the dead NAND was my primary motivation for learning how to build OE from sources.

My NAND failed after writing a movie on it but there are several reports on the forum of failures after update to various versions.

The best hypotesis I have is that the NAND usually fails after writing of some bigger files. During normal usage of the box there are only small writes but during the update the NAND gets more stressed and is more likely to fail.

My LE9 builds for MX2 all use the same kernel image and starting from 9.0.0 basically the same underlying OS so if the previous versions worked for you then it is highly unlikely the new build is the cause of your problem. Seems more like a NAND failure to me.

The new build is basically just a Kodi update.

I've just uploaded a new build based on 9.0.2 (Kodi 18.2).

LibreELEC-Amlogic_MX2.arm-9.0.2.tar

You can update from previous versions by placing the .tar file to the .update folder and reboot.

The upstream Kodi 18.2 contains a bunch of fixes for Amlogic from kszaq so the MX2 should now benefit from these as well:

Amlogic fixes from community builds by kszaq · Pull Request #15859 · xbmc/xbmc · GitHub

And also this PR is included in the build:

[Estuary] Fix order of TVShowTitle and Title by DaVukovic · Pull Request #15891 · xbmc/xbmc · GitHub

crackulator The zip file for 7.95.3 is available in the first post in this thread.

You can try to run the following command using the USB keyboard:

If it doesn't work then you can try:

Then report back with the results.

Actually I've just noticed this commit in Kodi 18 devel log which might have solved the analog AV output problem:

[AML] read display modes optionally from file · xbmc/[email protected] · GitHub

You can try to create a file named disp_cap in the /storage/.kodi/userdata/ folder and put 576cvbs text in it.

Or you can use the following command on SSH:

If you are running the latest LE 9.0.x build the analog AV output might start to work after Kodi restart.

Good luck!

Hi there.

1. Regarding the analog AV output I'm afraid there is currently no way to get it to work, sorry. There is no config.txt on the MX2.

2. To get the internal storage to work you need to create the LIBREELEC_DISK label on it. Turn on the SSH service, connect to the box using e.g. PuTTY (Download PuTTY - a free SSH and telnet client for Windows) and run the following command:

You can then remove the USB disk and reboot.

3. The Samba share is used only for updating from the 8.0.2 to 9.0.1.

You can find more details here (Update LibreELEC [LibreELEC.wiki]), but basically if you already have the 8.0.2 build working you just need to copy the .tar file to the /storage/.update folder (or to the Update Windows share) and reboot.

It is always good idea to do a backup before update!

EDIT: The recovery zip file for MX2 LE 9.0 is currently broken so that's why I only provide the update tar file. There is currently no other way of installing LE 9.0 than installing 8.0.2 and then update to LE 9.0.1 using the tar file.

New build based on 9.0.1 (Kodi 18.1).

LibreELEC-Amlogic_MX2.arm-9.0.1.tar

You can update from previous versions by placing the .tar file to the .update folder and reboot.

I don't want to make big promises but I can probably build and test community WP1 and MX2 images until the drop of amcodec in LE10 or at least until the revert of the commit is the only change needed to make it work.

That's generic Kodi 18 behaviour, you need to unset the file extensions in advancedsettings.xml.

See here:

RetroPlayer branch of Kodi

It is actually fast enough to handle some PSX games with the PCSX-reArmed but don't forget to disable the rewind support in Games menu to get full speed.

Btw. It seems that the DTB is based on the generic rk3399-box-rev2.dts:

linux-rockchip/rk3399-box-rev2.dts at rockchip-4.4 · Kwiboo/linux-rockchip · GitHub

The hdmi-sound, ir-int and ir-receiver nodes seem to be missing there as well.

Quote from Kwiboo

The mpp library will automatically activate deinterlacting using the IEP (Image Enhancement Processor), for this to happen the iep and iep_mmu node needs to be enabled in device-tree. Kodi will not show any deinterlace options or reflect if deinterlacer is used or not.

There is also a different post-processing unit in the VPU that should support deinterlacting, but this is not used by mpp library.

It is still unclear on how deinterlace will function in the drm prime rendering pipeline, hopefully the IEP can be exposed as a V4L2 device and a ffmpeg filter can be created that make use of such device or similar block on other platforms. Main focus on the drm prime rendering pipeline is to be cross platform compatible.

Please give me a link to dts and I can take a quick look and possible include the dts in my linux tree (I usually compare it to rockpro64 dts and reorder nodes in same order to make compare across the different devices easier).

Display More

Thanks, this is the info I was looking for.

I've posted the DTB to the H96 MAX thread:

H96 MAX RK3399

I've already added hdmi-sound, ir-int and ir-receiver nodes to the original Android DTB and I've also added a HDMI-CEC handle to the pinctrl-0 in HDMI and set audio-cards names.

The IEP nodes seem to be there and the deinterlacing seems to work as you say (Kodi doesn't reflect it but it works). I'd swear that I've checked that before and the deinterlacing was not working but it definitely does now with official LE 8.90.012.