RK3399 HDMI audio quality

    Quote from Joern-p

    hi mo123,

    i have now integrated the Rockchip change for the Rockpi4 device tree.

    But do not know exactly whether the problem could be.

    Here is the dtb file.

    Thanks.

    I also saw if I use an old u-boot package >5 months ago then LE also boots correctly again on every device.

    You don't perhaps know how fans work on RK3399?

    The Khadas Edge also has a fan like the nanopi4(rk3399-nanopi4-common.dtsi) but I can't seem to get it turning on automatically on LE with the 4.4 kernel. With mainline LE, the fan is working.

    If I use the NanoPi4 dts file, the fan starts spinning on the Edge but obviously doesn't boot because it's the incorrect dts/dtb used.

    Here is a kernel fan patch but I think it's for Android and not Linux(LE) - FAN: enable PWM FAN, add auto mode and factory test support · khadas/linux@10fdda2 · GitHub. The fan has 0 1 2 3 speeds, if it can automatically use speed 1, low speed, it would be great.

    The device runs quite hot if software decoding 1080p so having the fan work would be helpful with the older 4.4 kernel.

    Hi

    Do you know how to add the 'add 'uboot-set' in io-domain node' for Edge RK3399?

    The same patch of nanopi added to rk3399-khadas-edge.dtsi doesn't seem to boot, only if I use an older u-boot.

    Here are all the specific Edge Linux 4.4 kernel changes

    Commits · khadas/linux · GitHub

    I'll try to add and check what is different compared to your kernel to make the device more compatible.

    RockPi 4 with a heatsink works great so far and stays cool.

    Not sure why Khadas decided to use a noisy fan.

    The fan is working with LibreELEC with mainline kernel.

    I still couldn't get the fan working with the 4.4 kernel even with 8018716dd73adc85c8f5175290066bf6d5b4e70a commit, but maybe it's because I tested with an old u-boot or more kernel changes are missing, not sure.

    Thanks

    Hi m0123,

    For me it is not necessary.

    The system based on kernel 4.4 is stable for my needs.

    I will use LE 10 with the mainline kernel if the rk3399 support is stable.

    Hi, has anyone also problem with Direct Passthrough of DTS, DTS-HD and TrueHD on RockPi 4 ver A in Kodi ??
    I get only loud white noise or something...the same I get on Android TV images. I was able to transmit DTS-HD on Odroid C2 but now looking for How to exclude that it's even possible to get DTS-HD working on RockPi ??

    Has anyone experience DTS-HD playback issues ????

    What might the limitations might be for DTS-HD to work in Rock Pi 4 while it works on AMLogics ????

    Edited once, last by tuhajbej6 (August 6, 2020 at 6:19 PM).

    Quote from tuhajbej6

    Hi, has anyone also problem with Direct Passthrough of DTS, DTS-HD and TrueHD on RockPi 4 ver A in Kodi ??
    I get only loud white noise or something...the same I get on Android TV images. I was able to transmit DTS-HD on Odroid C2 but now looking for How to exclude that it's even possible to get DTS-HD working on RockPi ??

    Has anyone experience DTS-HD playback issues ????

    What might the limitations might be for DTS-HD to work in Rock Pi 4 while it works on AMLogics ????

    LibreELEC with 4.19 kernel possible?

    DTS-HD is working in my AndroidTV images for RockPi 4.

    Try setting keep device alive to off and send low audio noise to off.

    Back on the topic of audio quality, I managed to get rid of the HDMI audio clicks / glitches by installing and using PulseAudio (with tsched=yes, i.e. glitch-free mode). I guess the ALSA interrupt latency or variability is problematic on rk3399.

    With the current RK3399 release I have two issues on my RockPro64:

    1. HDMI audio passthrough is completely broken to my Denon AVR-S740H; it sounds like the AVR is treating it like PCM (i.e. just white-noise)

    2. The sound randomly cuts out in videos for anywhere from about half a second to 3 seconds. It can go an hour without doing this but then do it several times in a few minutes, but I've not made it through a 2 hour movie without this happening.

    • Official Post

    The project team are all unpaid volunteers writing HDMI and related HBR audio code from scratch and upstreaming it (slowly) to the Linux kernel in their private free time whilst having busy professional and family lives. If you feel progress is too slow, feel free to contribute the changes faster yourself, or fund a professional development house like Collabora to do the work, or continue using Android.

    Quote from sigmaris

    Back on the topic of audio quality, I managed to get rid of the HDMI audio clicks / glitches by installing and using PulseAudio (with tsched=yes, i.e. glitch-free mode). I guess the ALSA interrupt latency or variability is problematic on rk3399.

    I've been wondering if pulseaudio would be able to fix it. Would you happen to have a how to on doing this? I've implemented the settings from KOPRajs, but I feel that's not a long term fix really. I even have to do it with the newly released LE 10. Would be nice to have a more proper fix, and using pulseaudio would be great.

    Quote from butterkitty

    I've been wondering if pulseaudio would be able to fix it. Would you happen to have a how to on doing this? I've implemented the settings from KOPRajs, but I feel that's not a long term fix really. I even have to do it with the newly released LE 10. Would be nice to have a more proper fix, and using pulseaudio would be great.

    I'm afraid I don't have a how-to for LibreELEC, I am using Debian but with a custom kernel & FFmpeg with patches from LibreELEC. For me, I installed and enabled pulseaudio and added

    Code
    User=kodi
PAMName=login
TTYPath=/dev/tty1

    to the systemd unit file I use to run Kodi as a service, then it starts a user session for Kodi which includes pulseaudio. I am not familiar with how to do the same on LibreELEC though, sorry.

    PS: my original post was 2 years ago, I did a quick test of disabling pulseaudio now, and couldn't reproduce the audio glitches using only ALSA. It may have been fixed at some point in the past 2 years.

    I can eliminate the HDMI audio clicks / glitches if I limit the maximum audio volume to ~85%!

    Can anyone confirm this?

    Maybe something is configured incorrectly in the audio/HDMI driver here?

    Hmm, actually I have noticed something similar with my TV where I need to keep the volume in Kodi at about 33% to avoid severe audio distortion. This only affects my TV (Samsung UE40EH5000), but not another HDMI monitor I tested with. However I did experience the glitches/clicks problem on the HDMI monitor when I was using it.

    I thought the two problems weren’t related, but I guess they might be? Worth noting, the distortion at high volume happens on LibreELEC as well as my Debian install.

    Quote from ClashC

    I can eliminate the HDMI audio clicks / glitches if I limit the maximum audio volume to ~85%!

    Can anyone confirm this?

    Maybe something is configured incorrectly in the audio/HDMI driver here?

    I've noticed that the clicking is better when the output it lower.

    I've also notice that it happens predominantly in 5.1 or higher and if you limit output to 16bit, it seems a heck of a lot better. I find the higher the quality of audio, the more it pops. Usually the higher the bit depth, the worse it gets.