February 18Feb 18 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? Edited February 18Feb 18 by DeVILRuNNeR added specific dtb file ref
February 18Feb 18 Author 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])
February 20Feb 20 Author 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 Edited February 20Feb 20 by DeVILRuNNeR
February 21Feb 21 You should also consider the bootloader (type and version), in principle you do not need the dtb- package as the dtb files are also in the kernel package (enough when doing own extlinux). U-Boot philosophy is to provide just enough so that the kernel/initrd/DTB can load and started. Audio is not part of that I think. LE certainly used other bootloader and as you already showed has more non-upstreamed patches. See my experience:
February 21Feb 21 Author 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
February 21Feb 21 Author 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...
February 22Feb 22 Author 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. Edited February 22Feb 22 by DeVILRuNNeR
February 23Feb 23 Author https://github.com/chewitt/linux/commit/d39e2d1a2027e05de26af5bac575e99dedf7ce74
February 25Feb 25 Author Any chance of the above commit being adopted in future releases? It could make multichannel PCM hdmi audio work correctly.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.