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

    1x https://www.amazon.de/dp/B0C53D43JF
    1x https://www.amazon.de/dp/B08C4Z69LN

    If you want to boot local and not from the Network any NVMe SSD as ASUS docu says will do. I used my spare Sasmung 970 Evo 500 GB (way to big).

    Yes there are many less expensive N100 boxes even some are fanless, but most likely you never see a BIOS update and for the Feature CIR and CEC i did not see anywhere else.
    I just did send a HUNSN BM34 back. Nice Box but no wakeup at all except WOL. No CIR or CEC either. Dont really need any of these features, but to be able to use standby, IR or USB wakeup even from S5 is nice. When my Harmony Elite gives up i maybe need to change my setup and use CEC and/or CIR.

    What is now the next step for this issue?
    Will your fix get merged into the main libreelec repo? Or will people with newer intel cpus be dependent on your fork?

    Quote from racemaniac

    What is now the next step for this issue?
    Will your fix get merged into the main libreelec repo? Or will people with newer intel cpus be dependent on your fork?

    It's a workaround not a fix, so further investigation is needed to identify and resolve the root cause. Links to the Intel DRM issue tracker were posted already. The Intel devs that you need to contact are probably lurking in the #alsa-dev IRC channel on Libera and/or the #linux-media channel on OFTC too; but start with formally recording the issue on the tracker.

    I am pretty sure now the workaround does work (at least for me) and fixes the issue. For the testing i started 2024 with the MCU in chronological order after finishing Fast and Furious all movies.
    Next will be creating a issue at Intel drm/i915. I already had a look on issues there and how they look like and 1st i need to create account there. Hopefully i do that to the end of next week.

    I am willing to maintain the patched versions until it is fixed in official LE. That is "only" one extra device with 90min compile time for every release i do.

    A quick, maybe unrelated, the question to someone who knows about Intel drivers:

    why can I not playback UHD when watching TV via HTS client on Intel systems?

    It seems to work when I turn off HEVC VAAPI.

    Funnily, I can playback a recording of the uhd channel.

    Sometimes I can play live UHD when I use Hts via http, but not always.

    Where is this code located, who to ask? (the hts-client guys?)

    New workaround script for official LE 11 and 12, written and tested on official LE 11.0.6.

    SSH to your box an run
    curl https://sky42.libreelec.tv/testing/proptest/install.sh | bash /dev/stdin

    now you can run
    /storage/.config/activate-adl-10-bit-fix.sh

    or be sure it is in
    /storage/.config/autostart.sh
    and reboot


    Use the solution from post #46.

    After some more help and this time from jernej . Thank you.

    I have now a script to fix the audio problem for any LE11/12 without extra binary. The same script works on LE11 or 12.
    wget https://raw.githubusercontent.com/sky42src/LibreELEC.tv/11.80.5-240204/projects/Generic/filesystem/usr/bin/intel-gpu-max-10-bit.sh && chmod +x intel-gpu-max-10-bit.sh && ./intel-gpu-max-10-bit.sh

    I opened a pull request to make the helper script part of official LE.

    Generic: added intel-gpu-max-10-bit.sh helper by sky42src · Pull Request #8588 · LibreELEC/LibreELEC.tv
    This uses modetest to set max 10 bit to solve…
    github.com
    Quote from sky42

    I opened a pull request to make the helper script part of official LE

    Pursuing the fix upstream then submitting a backported kernel or intel driver patch will probably be faster. I think you'll find that script is a little too hacky for peoples tastes and i'd be surprised if it gets merged at this stage in the release cycle.


    Thanks. I just ordered a NUC12WSHi3 today so looks like I’ll need your script.

    I’m hoping you can make it available for some time as I’m sure others will need it too. Thanks again.

    Quote from chewitt

    It's a workaround not a fix, so further investigation is needed to identify and resolve the root cause. Links to the Intel DRM issue tracker were posted already. The Intel devs that you need to contact are probably lurking in the #alsa-dev IRC channel on Libera and/or the #linux-media channel on OFTC too; but start with formally recording the issue on the tracker.

    Does it matter if it's a workaround?

    I get you don't want workarounds permanently in your codebase, but an issue that probably affects all current gen intel processors, if you have a fix, shouldn't it somehow be given to the user in an easy way, and not relying on them finding a script in a forum topic?

    Could this fix be added in the form of an addon and when first opening libreelec on a 12/13/14th gen intel it suggest you install the addon to mitigate the issue in the intel driver bug?

    I just find it strange that a crucial fix to using this project on modern hardware would remain hidden here, there must be a better way to make it available, even if it is a workaround. I get the project wants to keep their code clean, but there must be something in between, and not just leaving your users out of luck unless they start googling to find the workaround you have but don't advertise or provide in an easy way.

    In context the number of users rocking up here with latest generation Intel hardware is small and in continuous slow in-decline for the last decade. So audience is not large, there is a workaround (albeit forum sourced) available, and 'Yes' adding hacky stuff to the core image matters and is something to be avoided; largely because once workarounds are merged history shows people end up being happy with the workaround and the root cause is never pursued. If you refuse the hack up-front there's a significantly higher probability of the real issue being resolved (tried and tested). Backporting patches merged/submitted upstream is a no-brainer.

    Quote from chewitt

    Pursuing the fix upstream then submitting a backported kernel or intel driver patch will probably be faster. I think you'll find that script is a little too hacky for peoples tastes and i'd be surprised if it gets merged at this stage in the release cycle.

    Ofc that is a hacky script because it is a workaround and not a fix. My focus was to make it usable with as many hints as possible.
    For more then 5 years i deliver contributions to this project. Do you have the impression i would not follow up and remove the script when there is a fix upstream?
    I can not pursue anything on that intel issue. It was days to prepare all the information and create clean infos for that issue. Now it sits there and nobody responsible has acted in any way at all. What would be the way to pursue that? Being pushy and asking when somebody is doing something? That is not very nice and i will not do that. If i could fix it i would have done it. Instead i try the next best thing and try to help users with the same problem.
    In your opinion the user of LE should be denied the easier workaround of including this hacky script and instead waiting that somebody will fix it upstream so the it comes to LE. Until then the users are screwed and poking in the dark if they hit the same issue. Buying cables or do other desperate things. From what i saw by researching it i found hints that it is a years old problem. Now i am doing something and being punished for it. That is how i feel.

    Quote from chewitt

    In context the number of users rocking up here with latest generation Intel hardware is small and in continuous slow in-decline for the last decade. So audience is not large, there is a workaround (albeit forum sourced) available, and 'Yes' adding hacky stuff to the core image matters and is something to be avoided; largely because once workarounds are merged history shows people end up being happy with the workaround and the root cause is never pursued. If you refuse the hack up-front there's a significantly higher probability of the real issue being resolved (tried and tested). Backporting patches merged/submitted upstream is a no-brainer.

    So if it is just a bunch of users they can be ignored for the good of the code base? .oO(i am being sarcastic)
    Again do you have the impression i will not follow up when Intel fixes that problem?
    And yes there is be a easier way for the users: to include my hacky script until Intel fixed it.
    The scope is unclear so i did not restrict when it will act, i already had some PCI id filtering in there, but i can only guess which PCI id are problematic.
    Your way leads to user download the script and with a new image with the fix it will not be removed and still be there and i have no chance in updating that script, because it is not part of the image. I could not put in the parameters when it is fixed, because i do not know them. And that is better in your opinion?

    chewitt What exactly do i need to do that it gets included now? So people with nice and expensive hardware can just use there hardware.

    Quote from chewitt

    In context the number of users rocking up here with latest generation Intel hardware is small and in continuous slow in-decline for the last decade. So audience is not large, there is a workaround (albeit forum sourced) available, and 'Yes' adding hacky stuff to the core image matters and is something to be avoided; largely because once workarounds are merged history shows people end up being happy with the workaround and the root cause is never pursued. If you refuse the hack up-front there's a significantly higher probability of the real issue being resolved (tried and tested). Backporting patches merged/submitted upstream is a no-brainer.

    Of course fixing the real issue is the real solution. But until then you've got an issue for a continuously growing number of potential users, and i don't get why you just want to leave them hanging.

    Hence why i was asking if there are in between options? The very least would be a message on first boot "your hardware has a known issue, you can find more info and a workaround on our forum". But you also don't address my addon idea or come up with a solution that would be acceptable for you.

    I get you don't want a codebase full of hacks, but this is obviously also not the solution. So what would be acceptable for you to deliver this workaround to your users without violating how you want the project to be? There is a lot between adding this to the main code forever and doing nothing at all for your users. Where can we meet in the middle and actually make this project viable for people with 12th gen & up NUCs until intel fixes the issue (if they end up fixing the issue that is).

    Quote from chewitt

    In context the number of users rocking up here with latest generation Intel hardware is small and in continuous slow in-decline for the last decade. So audience is not large, there is a workaround (albeit forum sourced) available, and 'Yes' adding hacky stuff to the core image matters and is something to be avoided; largely because once workarounds are merged history shows people end up being happy with the workaround and the root cause is never pursued. If you refuse the hack up-front there's a significantly higher probability of the real issue being resolved (tried and tested). Backporting patches merged/submitted upstream is a no-brainer.

    IMHO the latest Intel community isn't small and will grow up quickly. The Intel n100 boxes replaces all the RPi3 in my family for 4k media center. RPi4/5 are to expensive for the benefit they give...