RK3399 HDMI audio quality

  • 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.

    Edited once, last by KOPRajs (June 2, 2019 at 12:48 PM).

  • KOPRajs I have also noticed small audio issues on rk3399 using 4.4 kernel, on mainline I did not notice such issues, but I did not test enough on rk3399.

    Can you try with one of the mainline images at Index of /test/ and see there is an improvement or not. Mainline images should support multi-channel lpcm same as on 4.4 kernel.

  • 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 mp3@320kbps 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?

    Edited once, last by KOPRajs (September 17, 2019 at 5:12 PM).

  • I've been doing testing via the commit listed for the pull request here: Rockchip: add mainline linux support by Kwiboo · Pull Request #3560 · LibreELEC/LibreELEC.tv · GitHub

    From what I can tell, when I set the sample rate to fixed and either 44.1 or 48khz, the clicks and pops are a lot better, but are still there. When I up it past that they are VERY apparent.

    I tried hooking things up via 3.5mm jack on the device but I don't actually see the output as an option within kodi.

    I also tried to pair my bluetooth headset that I usually use with my phone to it, but I couldn't get bluetooth working on this commit version (I swear it works on 9.1.501 as I had paired a PS4 controller at one point)

    So, I can't really test outside of HDMI at the moment sadly, but I can confirm the pop issue.

  • I have also noticed small clicks/pops in HDMI audio in Kodi, not on LibreELEC but using a custom build of Debian Buster with 5.3 kernel.

    If the CPUfreq scaling governor is set to "performance" it doesn't happen for me.

    If the governor is the default "ondemand" I hear the clicks. So I suspect it's related to CPUfreq switching frequencies.

    KOPRajs and butterkitty on the mainline kernel, you could try running (as root)

    Code
    echo "performance" > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
    echo "performance" > /sys/devices/system/cpu/cpufreq/policy4/scaling_governor

    and then test HDMI audio. It'd be interesting to see if that fixes the issue.

  • 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 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:

    Code
    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/online

    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? :)

  • Everyone getting crackling audio

    Please post LibreELEC debug logs if you can, then it can help Rockchip to look into the issue faster and determine the cause.

    What happens if using interactive governor?

  • Hi,

    test setup

    SW: Mainline LibreElec + the kernel pull request 3560

    HW: RockPro4 connected to a Denon 477 via HDMI. For the first test nothing changed in libreelec, so no passthrough and just 2.0.

    Playback of mentioned Youtube Video via the plugin.

    Kodi Debug Log - But I didn't see anything special.

    Afterwards I enabled the verbose logging for ffmpeg, see attachment to the post. But there is nothing special in the Kodi log, or at least I don't see anything.

    Anything else that would be helpfull?

  • 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.

    Edited 2 times, last by KOPRajs (November 9, 2019 at 7:56 PM).

  • Hi

    I tried to also boot on a RockPi 4 RK3399 but couldn't get it to boot, no signal on tv.

    I copied the dtb file and edited the one in the extlinux file too.

    With the previous images from 17/11/2019, it booted correctly.

    Do you know if any big kernel, u-boot changes since then might be what is causing the non booting issue perhaps?

    I will just try different micro-sd card brands too.

    I don't have a uart cable so it's difficult to troubleshoot.