[x86-64] ASRock J3455-ITX problem with HBR audio passthrough

System

• Board: ASRock J3455-ITX (Intel Celeron J3455, Apollo Lake)
• LibreELEC: 12.2.1 (Generic.x86_64), Kodi 21.3 "Omega"
• Receiver: Onkyo TX-NR709
• Same HDMI cables and same receiver I was using ~5 years ago on an older LibreELEC build (roughly the 9.2/10.0 era), where TrueHD/DTS-HD MA passthrough worked — intermittently, but it worked. (Had to start the Receiver first and then boot the Kodi player machine - this is why I say intermittently)

Symptom

On current 12.2.1, Dolby TrueHD and DTS-HD MA passthrough produce no audio at all. Regular Dolby Digital (AC3) and DTS core passthrough work perfectly every time. Video and everything else plays back fine.

What I've ruled out

• Not a Kodi settings issue — passthrough is enabled correctly for both TrueHD and DTS-HD, and kodi.log shows clean negotiation every time:

  CAEStreamParser::SyncTrueHD - TrueHD stream detected (8 channels, 48000Hz)
  Creating audio stream (codec id: 86060, channels: 8, sample rate: 48000, pass-through)
  CAESinkALSA::Initialize - Opened device "hdmi:CARD=PCH,DEV=0,AES0=0x06,AES1=0x82,AES2=0x00,AES3=0x09"

(AES3=0x09 = non-audio/compressed bitstream flag correctly set.) Same clean result for DTS-HD MA via SyncDTS. Zero ALSA errors, no underruns, no sink failures, in every test.

• Not the EDID/ELD — /proc/asound/card0/eld#2.0 shows a fully valid, complete capability read from the Onkyo, including both HBR formats:

  sad6_coding_type   [0xb] DTS-HD
  sad6_rates         [0x1ec0] 44100 48000 88200 96000 176400 192000
  sad7_coding_type   [0xc] MLP (Dolby TrueHD)
  sad7_rates         [0x1480] 48000 96000 192000

Read at the exact same time as a failed playback attempt — so the driver has correct capability data and Kodi is using it correctly; the failure is downstream of both.

• Not the cable — swapped to a different HDMI cable connected to a different (aux) HDMI input on the receiver. Identical failure.
• Not video bandwidth contention — dropped resolution/refresh rate to the minimum possible. Identical failure. (Rules out the onboard DP→HDMI converter simply running out of bandwidth when video + HBR audio compete.)
• Not the receiver or general HDMI wiring — this exact receiver, on this exact cabling, passed TrueHD/DTS-HD MA (at least intermittently) on an older LibreELEC release a few years back. Since the AVR and cables haven't changed, that points at something that changed on the software/OS side between then and now.

My question

Has anyone else seen a regression like this on Apollo Lake (J3455/J4105-class) boards — HBR passthrough (TrueHD/DTS-HD MA) breaking while standard passthrough (AC3/DTS) keeps working — between older LibreELEC/Kodi builds and current 12.2.1/Kodi 21.3? I'm about to test an older LibreELEC image from a spare USB stick to confirm whether it's a kernel/i915 HDA-audio-component regression, but wanted to check if this is already a known issue before I go digging further.

Logs
Without debug
paste.libreelec.tv/unmined-gertude.log
With audio debug
paste.libreelec.tv/autopsic-bernadette.log

kodi:~ # cat /proc/asound/card0/eld#2.0
monitor_present         1
eld_valid               1
codec_pin_nid           0x5
codec_dev_id            0x0
codec_cvt_nid           0x2
monitor_name            TX-NR709
connection_type         DisplayPort
eld_version             [0x2] CEA-861D or below
edid_version            [0x3] CEA-861-B, C or D
manufacture_id          0xcb3d
product_id              0xb72
port_id                 0x0
support_hdcp            0
support_ai              1
audio_sync_delay        0
speakers                [0x4f] FL/FR LFE FC RL/RR RLC/RRC
sad_count               8
sad0_coding_type        [0x1] LPCM
sad0_channels           2
sad0_rates              [0x1ee0] 32000 44100 48000 88200 96000 176400 192000
sad0_bits               [0xe] 16 20 24
sad1_coding_type        [0x1] LPCM
sad1_channels           8
sad1_rates              [0x1ee0] 32000 44100 48000 88200 96000 176400 192000
sad1_bits               [0xe] 16 20 24
sad2_coding_type        [0x2] AC-3
sad2_channels           8
sad2_rates              [0xe0] 32000 44100 48000
sad2_max_bitrate        640000
sad3_coding_type        [0x7] DTS
sad3_channels           8
sad3_rates              [0xc0] 44100 48000
sad3_max_bitrate        1536000
sad4_coding_type        [0x9] DSD (One Bit Audio)
sad4_channels           6
sad4_rates              [0x40] 44100
sad5_coding_type        [0xa] E-AC-3/DD+ (Dolby Digital Plus)
sad5_channels           8
sad5_rates              [0xc0] 44100 48000
sad6_coding_type        [0xb] DTS-HD
sad6_channels           8
sad6_rates              [0x1ec0] 44100 48000 88200 96000 176400 192000
sad7_coding_type        [0xc] MLP (Dolby TrueHD)
sad7_channels           8
sad7_rates              [0x1480] 48000 96000 192000

I've upgraded BIOS to latest release (2025/1/15). You are correct, the motherboard uses a LSPCON chip for the DisplayPort to HDMI conversion.
I've reinstalled Libreelec using LibreELEC-Generic.x86_64-13.0-nightly-20260810-393623d.img.gz and my audio issue got worst. Unable to play any dts or dd audio tracks, even with passthrough disabled, the audio was garbled.

I've downgraded to LibreELEC-Generic.x86_64-12.2.1.img.gz and I'm at the same status from my original post.

Not sure what happen throughout the years, but this exact setup used to work and playback high bitrate audio.