I've started to chase this through Team Kodi contacts. We have direct chat access to several people, one of whom has been copied into the ticket. These things take time and (us) trying to escalate them is often counterproductive.
So, any updates?
Posts by racemaniac
-
-
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 :). -
Hence why you include the nice workaround into libreelec for now...
But it's awesome to hear that there is contact with the Intel team and that a proper fix will hopefully arrive sooner rather than later :). -
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.
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 N100And 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. -
Display More
So now i established my new baseline where i can reproduce a working and a non working version with LE11 and LE12
LE11 11.0.4-#240109 https://sky42.libreelec.tv/release/11.0/G…/Generic-ADL10/
- Generic-ADL10 is working perfect for me with Intel N100
- Generic-BT2020 is the counterpart without the 10 bit patch as the only difference
- tested 1 movie 1st BT2020 after 3x (about 5mnin) audio glitches switch to ADL10 and the rest was flawless
- sources https://github.com/sky42src/LibreELEC.tv/tree/11.0.4-240109
LE12 11.80.5-#240109 https://sky42.libreelec.tv/testing/12.0/G…/Generic-ADL10/
(i would not use LE12, because kodi + mysql is at the moment very wonky and OS nfs4 is broken too)
- 2x downgrades in my 11.80.5-#240109 release to get mysql and OS nfs4 working
- Generic-ADL10 is working perfect for me with Intel N100
- Generic is the counterpart without the 10 bit patch as the only difference
- tested 1 movie 1st Generic after 3x (about 3min) audio glitches switch to ADL10 and the rest was flawless
- sources https://github.com/sky42src/LibreELEC.tv/tree/11.80.5-240109What 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.
