You might want to look at RK3399 HDMI audio quality.
You also might want to try the original H96 MAX device tree from Android which I've modified to work in LE (H96 MAX RK3399). Just replace the rk3399-rockpro64.dtb on the SD card with the downloaded file.
Hi,
I've tested the Joern's image and I can confirm that both audio issues from the original post seem to be resolved for me. Good job!
Unfortunately the image introduces new issues for me on the H96 MAX RK3399 box. USB-C is not working anymore, no deinterlacing etc. However, some of the issues are probably related to the not updated device tree for H96 MAX. I'm using the original device tree from Android which I've modified to work with the official LE image (H96 MAX RK3399).
Hopefully Kwiboo is listening and some of the Joern's changes will make it to the official release!
EDIT: While the above new issues seem to be related to the device tree the following 2 seem not:
1. While playing the Hobbit video from YouTube mentioned earlier the audio is finally without any cracking but approximately twice per the video the HDMI mode change occurs resulting in half a second drop of the audio and an OSD with the HDMI mode shown on the TV.
2. Sometimes the HDMI mode is incorrectly set to 4K instead of 1080p resulting in the video or the GUI being shown only in the quarter of the screen. Subsequent mode change brings it back to normal.
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:
echo "powersave" > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo "performance" > /sys/devices/system/cpu/cpufreq/policy4/scaling_governor
echo "0" > /sys/devices/system/cpu/cpu0/online
echo "0" > /sys/devices/system/cpu/cpu1/online
echo "0" > /sys/devices/system/cpu/cpu2/online
echo "0" > /sys/devices/system/cpu/cpu3/onlineBasically 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.
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:
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.
