Intel Alder Lake 2160p @ 23.976 Hz passthrough HD Audio dropouts (i7-1270p/N100)

    sky42 since I don't follow this topic, is TL;DR version that "max bpc" property is 0 at boot and your script bumps it to 10?

    If so, this is from what I can tell kernel bug. First, lower limit is 8, not 0. Secondly, kernel code initializes "max bpc" property to max, but it's later overwritten to 0 in reset state. This will be changed in large HDMI related patch series, more specifically in patch 10. However, it's not marked as a fix (since it's part of rework and I'm not sure if it's really considered as a fix), so it won't land in stable kernels.

    jernej as short as i can

    playback screen resolution 3840x2160 @ 23.976 Hz Pixel Depth 12 bit results in HD audio dropout on at least i7-1270p and N100
    - Pixel Depth reported by my Denon AVR
    - i use only 2160p in all refresh rates
    why is long and stated here https://forum.kodi.tv/showthread.php?tid=344912

    problem goes away
    - playback 2160p @ 24 Hz
    - playback 2160p @ 23.976 Hz with max bpc 10 (Denon reports pixel depth 10 bit)

    other infos
    - max bpc set to 10 it still uses 8 bit pixel depth with e.g. DVD remux
    - the GUI comes up at boot in 4K60 with 8 bit

    All i did was try the matrix of settings and find out when it is OK. Hints to do what are from smp and from you (removing the need of proptest).
    I have no clue whatsoever about GPU kernel drivers. Just stating facts about things i tested and try to create a easy to use workaround.

    Quote from sky42

    jernej as short as i can

    playback screen resolution 3840x2160 @ 23.976 Hz Pixel Depth 12 bit results in HD audio dropout on at least i7-1270p and N100

    And i have the same issue with the i5-1340p, so 13th gen is also affected. I'm now using the custom build that was posted in this thread as it resolved any playback issues for me.

    And the main question is now, if the workaround is the only solution at this point, is there a decent way to make it available in the main release?

    As said above, the N100 is seriously gaining in popularity as it's matching the high end rpi5's in price, and offers better performance and x86. So having libreelec working properly on it would really be a good thing for this project.

    I’ll be using the sky42 fix but I’d prefer a kernel fix. I don’t want to block 12bit output. Call me stupid but I think one day we’ll see a Dolby Vision decode/conversion to 12bit HDR.

    Quote from chewitt

    And a reply: https://gitlab.freedesktop.org/drm/intel/-/is…99#note_2270390

    Support works a triage script like all support teams: start with testing latest to eliminate bugs that have already been fixed, then if the issue still exists start digging for more. Be responsive, as they have hundreds of other things on their to-do list :)

    It's great that intel might be having a look at it sometime.

    The question is what can libreelec do right now for its users? I get it, ideally intel solves it by next week, and it's not an issue, but most likely that'll drag on for way too long, if they ever come around to fix it. And we have a workaround right here right now, so can we please start figuring out what would be a reasonable way to get the workaround into libreelec?

    And just in general, shouldn't a project like this have a way to get workarounds like this to a user? I can imagine stuff like this happening from time to time, and just having a process to get a temporary fix to users seems like a very useful thing to have.

    Edited once, last by racemaniac (February 6, 2024 at 9:39 AM).

    yamcenutzer IIRC Rocket Lake do have Gen11 GPU and that is the 1st Xe GPU. Assuming that uses the same part of the kernel driver as Gen12 GPUs do: yes that can change your NUC too.

    There is no harm in trying the script from post 46.

    for the record, the issue is already old.

    Thread

    LE10/11 TrueHD + ATMOS audio drops

    Hi,

    i have asked already in the kodi forum, but i've got no response at all and maybe it is more an issue with LE than kodi.

    https://forum.kodi.tv/showthread.php…2815#pid3072815

    In that thread a sample file was shared and also reflect my issue which is not fixed for me and i want to figure out, why i got that audio drops.

    With latest LE10 Release and now master LE11 from 01.feb. the issue has not changed for me.

    My system is an asrock 4105j with 8 gb ram and a ssd hdd and connected via 1gbit eth to…
    dreamer
    February 4, 2022 at 8:26 AM
    [BUG]LE10/LE11 HBR Audio PT Audio issue with [email protected] with J4105 · Issue #6237 · LibreELEC/LibreELEC.tv
    Describe the bug As a starting point i need more guidance and knowledge of some experts. After serveral bug fixes of truehd pt in kodi last time my hope was to…
    github.com


    i was asking for help, there was no interest in the past. good to see, that something is happend now.

    Quote from dreamer

    for the record, the issue is already old.

    Thread

    LE10/11 TrueHD + ATMOS audio drops

    Hi,

    i have asked already in the kodi forum, but i've got no response at all and maybe it is more an issue with LE than kodi.

    https://forum.kodi.tv/showthread.php…2815#pid3072815

    In that thread a sample file was shared and also reflect my issue which is not fixed for me and i want to figure out, why i got that audio drops.

    With latest LE10 Release and now master LE11 from 01.feb. the issue has not changed for me.

    My system is an asrock 4105j with 8 gb ram and a ssd hdd and connected via 1gbit eth to…
    dreamer
    February 4, 2022 at 8:26 AM

    https://github.com/LibreELEC/LibreELEC.tv/issues/6237


    i was asking for help, there was no interest in the past. good to see, that something is happend now.

    I just hope they put something in the official libreelec release so user can find a solution for this issue without having to get cutom builds or scripts from that one forum thread you have to find...

    Pleaassee libreelec devs, get this released properly somewhere, it'll make this awesome project viable for a lot of builds, especially with things like the intel N100 gaining popularity.

    Quote from Da Flex

    Sure. sky42 is already in contact with Intel developers.

    And if intel just puts it on the long list of "issues we might one day tackle" and doesn't do anything on it for years?

    There is a workaround here and now, for an issue that's been causing problems ifor libreelec for years now (as evidenced by the thread dreamer linked to)... Why are you guys so against actually helping your users right now and just pointing to intel for all responsibility? (intel, which in the thread of 2 years ago also got a ticket for this exact issue, and so hasn't fixed it in all this time...)

    I get it, it sucks being dependent on a broken piece of code, but that's the life of a programmer. I'm also a programmer, i've had to add comments in my code for stupid/dirty workarounds around very specific issues in things we depend on or interface with. But in the end my user just needs it to work, not have me play the blame game and be like "technically this is microsofts fault, ok, they'll probably never fix it, and i can work around it, but yeah, it's not my fault so too bad for you".

    I'm sorry, i just don't get it. Why on purpose sabotage your project and make it not work properly on fairly popular hardware (the longer this thread goes on, the more generations of intel cpus come into scope, and nuc & nuc like devices are pretty popular in the htpc world). What do you have to gain by being like "yeah, it's a workaround, so we don't do anything with it, except for thoughts & prayers that intel will respond to a ticket that there is an intermittent audio issue when playing 4k hdr content at 23.97 fps, which will for sure be their top priority (especially since the thread from 2 years ago with the same issue links a ticket back then, so intel didn't fix it in the 2 years since the previous ticket was made).

    This project is great, it has so much promise, so why tank it for people with an intel htpc by playing the blame game with intel and refusing to incorporate this workaround in some way that's satisfactory for you guys until intel resolves the root cause (if they ever do so).

    I've even done suggestions asking what would be acceptable to you. How about detecting the system will have this issue and just giving your user a dialog explaining there is a known intel issue, and pointing them to this thread, or a similar thread with manual mitigation options? Or releasing the workaround via a plugin that's easily findable for users with an affect intel cpu or ...

    But it's really frustrating to see a really nice project like this being like "it's technically not our fault, so even if we can help our users, we won't"... whyyyyy???? that's such a ridiculous hill to die on.... Why bother making something like this if you then refuse to take even the slightest action to help your users when a case like this presents itself? I just don't get it...

    Now i did a pipewire test on this problem here.
    In short it does not help and the same fix with 10 bit helps too with pipewire + GBM or Wayalnd.

    For that result i had to work a bit. After getting a hint from lrusak pointing over here https://github.com/xbmc/xbmc/comm…e50cb77f429698a and building LE with Pipewire only i had no success get passthrough working. Then i did setup a baseline with Ubuntu 23.10, learned to compile Kodi my self the right way. Then i was able to test with GBM and Wayland with Pipewire only. And as i stated already it does not help the problem in this thread. Both configs work with the same fix from post 46.

    I teached my script to detect if 10 bit is already set and have a idea to detect GPU version from the script and only activate if it is a new GPU (without knowing all PCI IDs).

    Quote from Da Flex

    Sure. sky42 is already in contact with Intel developers.

    So, out of curiosity, how long will we wait for the Intel developers.
    It's now been a month since their one & only reply (which was asking for a second test hoping there was already a solution).

    In between Sky42 seems to have been refining his workaround to detect when it's needed, so it won't affect machines that don't need it.

    Are we getting closer to getting this fix in the main release, or are we just going to wait for Intel forever (since the issue from 2 years ago regarding the same issue is also still open...)