Posts by racemaniac

    Nice to know that a Yamaha also has the same issues, so it's not just Denon.

    And we now have builds of Sky42 that kind of work around the issue, but a real fix would be nice.

    I also use a Denon receiver and have the issue.

    I did find an interesting thread on the Kodi forum where they found the same (or at least very similar) issue, and think it's an issue with the audio clocks in that mode causing issues:
    Atmos audio drops / cuts on Denon X2800H and 24p playback

    They made this ticket for intel: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/8276

    Sounds very close to what we're experiencing.

    And after reading their thread, if taking the Denon receiver out of the equation solves the ticket, we should also test a non intel source on the denon to see if the issue persists. Because if other devices can perfectly play 4k hdr 24p through the Denon receiver, and only with intel we get the audio dropouts, it's some incompatibility between intel & Denon that coulds still have the root cause at either side.

    So these are builds containing the required kernel patch so the issue doesn't happen?

    I'm so far using the old build you once posted here of LE11 with this issue fixed. I'm trying to upgrade to these builds, but it's complaining that my platform is generic-ADL10 and these builds are for generic-BT2020, from googling BT2020 is de SDR standard, so do these versions completely disable hdr, or do they still allow for 10bit hdr?

    And it seems the issue on the intel gitlab is completely stalled as cannot reproduce, so in general, what's next regarding this issue? It'd be a real shame if all this nice new intel hardware could not be properly supported by libreelec...

    No update so far on the Intel case.

    Btw, immense thanks on all the work you've done so far on this ticket. Your build/script really make LibreEelec usable on modern Intel hardware (at least for those who like to play 4K), and LibreElec perfectly fits what i wanted to do with my Intel Nuc.

    I hope we'll get a more permanent fix somehow in the near future, but at least you've given some way to get it all to work :).

    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...)

    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...

    for the record, the issue is already old.

    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.

    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.

    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.

    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).

    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.

    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?

    Ah, i also made a thread about this issue, didn't notice it wasn't being discussed here already: Very short audio cut outs every ~5 minutes

    I just did an experiment: i went into audio settings and just tried changing random settings to see if it would have any effect, and not 100% sure about it yet, but disabling "send low level noise" seems to have fixed the issue on my end. I just watched an entire episode of 50 minutes without noticing this happening at all, while before it was just like you said every 5 minutes or so audio would drop for a second.

    Give it a try & see if it makes a change on your end. No clue how the settings could be related, but it seems to have worked on my end for some mysterious reason.

    Hmm, tested a bit more now, still have the issue... Maybe it's z bit less now or I just happened to test on a file that for some reason didn't trigger the issue.

    It would be nice to find a real fix for this issue though..

    Ah, i also made a thread about this issue, didn't notice it wasn't being discussed here already: Very short audio cut outs every ~5 minutes

    I just did an experiment: i went into audio settings and just tried changing random settings to see if it would have any effect, and not 100% sure about it yet, but disabling "send low level noise" seems to have fixed the issue on my end. I just watched an entire episode of 50 minutes without noticing this happening at all, while before it was just like you said every 5 minutes or so audio would drop for a second.

    Give it a try & see if it makes a change on your end. No clue how the settings could be related, but it seems to have worked on my end for some mysterious reason.

    Hi, i just installed LibreELEC on my 13th generation NUC to give it a try, and it's working pretty well, except every ~5 minutes audio cuts out for a second or so... Anyone got an idea what could be the cause/how to figure it out. I've enabled debug logging and scrolled though the logs at the time of one such hiccups in the audio, but can't really find anything it seems.