Posts by racemaniac

Quote from jbinkley60

I've been watching this thread for a long time and have had an Intel NUC (8i7BEK) and a newer N100 working with a Yamaha RX-A3080 AVR. Both Intel platforms have the same audio dropout issues with Dolby Atmos and other bitstream audio sources. I've been living with this issue on Intel for a few years.

I recently switched to a Beelink SER6 platform with an AMD processor and GPU. So far no dropouts with my Yamaha AVR. I realize it's way overkill but it's also lightning fast and no more dropouts. Prior to the Beelink SER6 I had tried a Raspberry Pi 5 for a few months with my AVR and no dropouts either. All running prior and the latest versions of LibreELEC.

I even tried OSMC and the Vero 4K+ and Vero V with no dropouts. Only LibreELEC with the Intel platforms have dropouts in my setup. I've not tried running Windows / Kodi on any of the Intel; mini-PCs.

Thanks,

Jeff

.

Display More

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.

Quote from sky42

I managed to build a LE12 with kernel 6.9 from master that you can download here https://sky42.libreelec.tv/release/12.0/G…020/kernel-6.9/.
This is with as less as possible changes. Just 6.9.5 and a systemd patch. No encryption or lvm yet.

smp thanks for the XE driver tip. I did just do that and it does not solve the problem.

All of you that want to test the XE driver with kernel 6.9
- find your PCI id with lspci -nn |grep  -Ei 'VGA|DISPLAY'
- for me that is 00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-N [UHD Graphics] [8086:46d1]
- set kernel boot parameter like i915.force_probe=!46d1 xe.force_probe=46d1
- disable 10 bit workaround touch /storage/.dont-activate-10-bit-max (the script will fail because it can not handle xe)
- reboot
- check with lspci -vs 00:02.0 and look for Kernel driver in use: xe

Display More

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

Anyone know if there are any updates on this? Is Intel still trying to figure it out?

Quote from chewitt

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?

Quote from sky42

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

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

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

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

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.

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

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.

Quote from sky42

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

Display More

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

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.