Posts by Link01

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

    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.

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


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


    Code
      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