DeVILRuNNeR

Any chance of the above commit being adopted in future releases? It could make multichannel PCM hdmi audio work correctly.

https://github.com/chewitt/linux/commit/d39e2d1a2027e05de26af5bac575e99dedf7ce74

Just tried stock DietPI & Armbian builds using both current-rockchip64 and edge-rockchip64 utilizing U-Boot - thus completely eliminating the EDK2 UEFI factor. None handle multichannel audio correctly so I guess there is something still not mature enough in mainline/upstream for this. kernel-rk35xx-vendor:6.1.115 works perfectly even with EDK2 UEFI. Perhaps the Armbian devs need to take a look at what LibreELEC is doing as they managed to get it working in their mainline/upstream kernels.

I just tried booting this LibreELEC test build on my nanopi R6S and to my amazement everything worked great in that build/kernel/bootloader. This means it is technically possible and the ingredients are out there, to bad it isn't on Armbian yet...

Thanks for your insights @eselarm. I was led to believe that the bootloader could not have any impact on this - guess AI is wrong again 😅 Anyhow I am running EDK2-UEFI v1.1 so might try one of the later artifacts

I just tried LibreELEC 13 testing builds as they are also running kernel 6.18. Audio seems to work there and I can hear all channels or speakers. I guess LibreELEC includes HDMI audio support patches for RK3588/S and NanoPi R6S that Armbian hasn’t incorporated yet ? The ALSA rockchip-i2s-tdm driver needs to support more than 8 TDM slots or support the HDMI multi-TDM mapping for 5.1 / 7.1. LibreELEC patches

Some logs that might help in resolving: cat /proc/asound/card0/eld* monitor_name SONY AVAMP connection_type HDMI eld_version [0x2] CEA-861D or below edid_version [0x3] CEA-861-B, C or D manufacture_id 0xd94d product_id 0x9301 port_id 0x0 support_hdcp 0 support_ai 1 audio_sync_delay 0 speakers [0x5f] FL/FR LFE FC RL/RR RC RLC/RRC sad_count 12 sad0_coding_type [0xc] MLP (Dolby TrueHD) sad0_channels 2 sad0_rates [0x1ec0] 44100 48000 88200 96000 176400 192000 sad1_coding_type [0xc] MLP (Dolby TrueHD) sad1_channels 6 sad1_rates [0x1ec0] 44100 48000 88200 96000 176400 192000 sad2_coding_type [0xc] MLP (Dolby TrueHD) sad2_channels 8 sad2_rates [0x6c0] 44100 48000 88200 96000 sad3_coding_type [0xb] DTS-HD sad3_channels 2 sad3_rates [0x1ec0] 44100 48000 88200 96000 176400 192000 sad4_coding_type [0xb] DTS-HD sad4_channels 6 sad4_rates [0x1ec0] 44100 48000 88200 96000 176400 192000 sad5_coding_type [0xb] DTS-HD sad5_channels 8 sad5_rates [0x6c0] 44100 48000 88200 96000 sad6_coding_type [0x1] LPCM sad6_channels 2 sad6_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad6_bits [0xe] 16 20 24 sad7_coding_type [0x1] LPCM sad7_channels 6 sad7_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad7_bits [0xe] 16 20 24 sad8_coding_type [0x1] LPCM sad8_channels 8 sad8_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad8_bits [0xe] 16 20 24 sad9_coding_type [0x2] AC-3 sad9_channels 6 sad9_rates [0xe0] 32000 44100 48000 sad9_max_bitrate 680000 sad10_coding_type [0x7] DTS sad10_channels 6 sad10_rates [0x6e0] 32000 44100 48000 88200 96000 sad10_max_bitrate 1536000 sad11_coding_type [0xa] E-AC-3/DD+ (Dolby Digital Plus) sad11_channels 8 sad11_rates [0xc0] 44100 48000 dmesg | grep -i hdmi [ 0.024452] /vop@fdd90000: Fixed dependency cycle(s) with /hdmi@fde80000 [ 0.024468] /hdmi@fde80000: Fixed dependency cycle(s) with /vop@fdd90000 [ 0.030657] /hdmi@fde80000: Fixed dependency cycle(s) with /hdmi-con [ 0.030674] /hdmi-con: Fixed dependency cycle(s) with /hdmi@fde80000 [ 1.328504] dwhdmiqp-rockchip fde80000.hdmi: registered DesignWare HDMI QP I2C bus driver [ 1.329303] rockchip-drm display-subsystem: bound fde80000.hdmi (ops rockchip_drm_fini [rockchipdrm]) [77523.181767] hdmi-audio-codec hdmi-audio-codec.4.auto: HDMI: Unknown ELD version 0 [77523.184450] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC error (-19): at snd_soc_dai_prepare() on i2s-hifi [77529.747875] hdmi-audio-codec hdmi-audio-codec.4.auto: HDMI: Unknown ELD version 0 [77529.749599] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC error (-19): at snd_soc_dai_prepare() on i2s-hifi [84820.893274] hdmi-audio-codec hdmi-audio-codec.4.auto: HDMI: Unknown ELD version 0 [84947.092875] dwhdmiqp-rockchip fde80000.hdmi: registered DesignWare HDMI QP I2C bus driver [84947.100550] rockchip-drm display-subsystem: bound fde80000.hdmi (ops rockchip_drm_fini [rockchipdrm])

Does anybody know how one could correct multichannel HDMI audio mapping in the current-rockchip64 build or kernel? When I run speaker-test -c6 -D plughw:0,0 on (kernel) 6.1.115-vendor-rk35xx + (dtb) dtb-6.1.115-vendor-rk35xx Everything is mapped correctly and I hear audio from all the correct channels. When I run the same command on (kernel) 6.18.12-current-rockchip64 + (dtb) dtb-6.18.12-current-rockchip64 I get no audio on center and rear right channels (others are working). Is this a mistake or error in the DTB file of dtb-6.18.12-current-rockchip64 (rk3588s-nanopi-r6s.dtb) ? How can we correct this?

Perhaps I can help to figure it out and look into something specific from the vendor image or kernel? It's apparently using a bespoke kernel wiki friendlyelec link

Thanks for your feedback all. To look on the positives: I have learned allot from these endeavours. My overall key take away is that off the shelf software support or available images is key with this kind of hardware. Any 'hacking' or custom builds is going to cost way more then the hardware itself and as this example proved might not even work at all. Hope these gmac driver issues get sorted for the Future but for now I am going to run thé vendor images.

I was running the UEFI generic build with the 6.12 kernel and dtbs applied through the grub loader. I didn't feel like going through all these hoops anymore and went back to the friendlyelec builds that work fine. No vlan or driver issues there. Not what i really wanted but this is just to much weird issues. Note: tried installing or running their kernel.deb that i have but refused to install. It complained about some board or machine info (in /proc) not being there. This dtb, DTS, dtbo thing is really sh*t and a shame on arm platforms compared to amd64.

More then willing to test on my NanoPi but not sure how I would need to compile 🙄

That is amazing ! Are you able to have more then 4 VLANs on this interface? Perhaps a stupid question but how can I apply this potential fix to my GMAC driver? On a side note: I am running a NanoPI R6C that only has 2 interfaces; yet it's showing 3 interfaces available to me 🤐

Did anybody figure this problem out? I just also figured out this is still a problem on this onboard gmac ethernet adapter. Apparently this is a driver problem and was resolved in immortalwrt or openwrt. https://github.com/immortalwrt/immortalwrt/commit/07e476cac84e52d2f3d7d8afa9cbae57d9a97ffd How would one go about fixing this for armbian?