AppleHDA scheint nicht zuverlässig zu laden

Hast du nicht schon einen Thread zu diesem Thema?

Edit: Sorry, hab dich verwechselt.

Nope.. hat er nicht...

Keksfamilie

Wenn du innerhalb von "IORegistryExplorer" nach "HDEF" suchst, bekommst du auch das von dir verlinkte Bild zu sehen. Nimm die Suche raus und scrolle bis zu "HDEF", dann siehst du auch den folgenden Baum.

Das Problem ist ja, dass diese neuen Rechner alle ein Intel-Device vor dem eigentlichen Realtek-Audio haben, was sich als Audio-Chip ausgibt.

Sieht man sehr gut unter Windows in den Hardware-Eigenschaften.

Es betrifft alle 400Series und neu die 500Series. Letztere haben heute im neuen Release AppleALC auch zwei neue Controller-Patches bekommen.

Diese Sache ist aber lange bekannt und es gibt für Dein Device 6c8 bereits seit AppleALC 1.5.1 einen Controller-Patch. (https://github.com/acidanthera/AppleALC/releases)

Erst heute mit dem neuen Release AppleALC kamen 2 neue Controller-Patches für 500Series (Z590).

Leider habe ich bis dato noch nie einen neuen Codec für Z490 oder Z590 gesehen, halt nur die Controller-Patches.

Dies liegt wohl auch daran, dass selbst Linux damit nicht klar kommt ohne Fake Device-ID und somit keine Codec-Dump's möglich sind.

Dein Controller wird aber seit AppleALC 1.5.1 wohl erkannt. In Deinem ersten Bild Post #1 injectest Du die alc-layout-id 2, welche wohl nicht passt.

Wenn die Knoten nicht passen, dann wird es auch keine Geräte beim Audio geben, selbst wenn der Controller in AppleALC erkannt wird.

Ich kann Dir nur empfehlen, versuche alle layoutID's des entsprechenden Realtek-Chip's durch. Mit viel Glück sind die Knoten gleich oder fast gleich und Du bekommst einige Audio-Geräte.

Ferner, versuche mittels Linux-Live ein Codec-Dump zu machen!

Keksfamilie was soll der folgende eintrag in deiner EFI bewirken?
alc-delay --> 3000

Bei Comet Lake sollte dieser auf
PciRoot(0x0)/Pci(0x1b,0x0)

lauten,

nicht auf

(0x1F,0x3)

wie bei dir.

Ich habe den Codec_Dump mal gewandelt. Deine Knoten sind im Prinzip mit vielen ID's gängig. Am Besten würde wohl die layoutID 100 passen, welche für einen MSI Z370-A PRO entwickelt wurde. Die Knoten sind dort identisch.

Dein Problem liegt aber vermutlich ganz woanders. Habe mir Deine EFI mal angesehen.

Du hast keine IRQ-Fixes gemacht, ohne die AppleALC keine Geräte lädt.

Nutze dafür das Script SSDTTime von GitHub. Hierfür brauchst Du die Clean-DSDT.

SSDTTime zeigt Dir dann die nötigen Patches, welche Du in der OC config.plist im Bereich ACPI/patch einbinden kannst.

Genauer gesagt, muss bei RTC und TIMR die 0 und die 8 (manchmal auch noch die 11) aus dem irqnoflags gelöscht werden.

Die 2 bei IPIC ist für Audio nicht wichtig, wird bei SSDTTime oft mit angezeigt. Wenn ein Patch für IPIC angeboten wird, kann man den auch setzen.

Die 0, 8 und 11 werden für HPET gesetzt. Evtl. brauchst Du auch noch den HPET-Patch von SSDTTime.

Wenn Du mal im System das Tool MaciASL startest, dann wird die aktuelle System-DSDT geladen. Diese kannst Du ja hier mal posten, bzw. Dir ansehen, wie die Bereiche RTC, TIMR und HPET aktuell aussehen.

Setze Dich mal mit SSDTTime auseinander! Ich denke, danach werden sicher Geräte beim Audio geladen.

Auf all Deinen Bildern hier im Thread zeigt Dein Audio auf 1F und nicht auf 1B. Viele neuere Rechner haben 1F.

Welche Adresse steht denn in der clean-DSDT bei HDEF oder HDAS?

Wenn es 1F ist, dann könntest Du in Section UEFI/Audio den Pfad auch in 1F ändern, falls Du mal Startsound haben möchtest. Dort steht noch die 1B.

Die IRQ-Patches hast Du perfekt gemacht.

Hast Du danach schon mal getestet, ob Du Audiogeräte bekommst, z.B. mit der layoutID 100 ?

Ich rate auch bei allen Test's zum Bootflag z.B. alcid=100

Die Sache mit HPET und SSDTTime ist nicht immer ganz perfekt, hatte die gleichen Probleme auf meinem Lenovo.

SSDTTime will es immer in die _CSR legen.

In meiner SSDT für HPET ist es nun in der BUF0-Methode, in dem Fall nur die 0 und 8, aber der Rechner geht perfekt. Beispiel:

Als Experte fällt mir hier grt ein.

guckst du mal da: KLIKK

wir hatten das problem, dass zwar die ssdt-hpet (nicht die von ssdt-time, ist in dem thread verlinkt) sehr gut und überzeugend aussah, aber das renaming mit OC nicht so richtig reibungslos funktionierte.

das musste quasi zu fuss erledigt werden:

erstmal zählen, wieviele _CRS in der dsdt vor dem umzubenennenden vorkommen, und zwar vor dem letzten, was zu ändern ist (hier im TIMR). die zahl in das feld "skip" eintragen, reboot, mit maciasl gucken, wo der rename gelandet ist (was da wie gezählt wird, kommt mir höchst spanisch vor, weil der rename nicht dort landet, wo man es nach der zählerei eigentlich erwartet), nachzählen, wie der versatz ist, "skip" entsprechend korrigieren, gucken, korrigieren... bis der rename passt. dann kann man dahinter(!!!) die nächsten renames setzen, von unten nach oben sozusagen. danach griff die ssdt-hpet, und mit dem richtigen layout gab es dann auch ton.

Den Zirkus muss man jetzt nicht mehr tun, im neuen OoenCore ist dafür eint tolle Funktion eingebaut, um ein ACPI-Patch exklusiv auf ein bestimmtes Device ausführen zu lassen. Einfach mal reinschauen, die ersten beiden Einträge studieren.

Zitat von apfelnico

..., die ersten beiden Einträge studieren.

Klingt interessant, aber die ersten beiden Einträge wovon? Stehe gerade auf dem Schlauch.

So sieht's zum Beispiel aus:

das hatten wir stehen, ich hab mich so richtig gefreut, weil ich darauf spekulierte, die zählerei bleibenlassen zu können, und es hat definitiv nicht funktioniert (pfade hab ich kontrolliert ). destawegen dann doch zählen wie der teufel... OC 0.6.8

Man kann natürlich auch die DSDT in einen Hexeditor werfen, die benötigte Stelle suchen und bissel Bits davor mitnehmen, damit man ein exklusives Ergebnis bekommt.

ganz schön umständlich..

aber klar, ginge auch, aber mit dem zählen hats ja auch geklappt. und prüfen muss man ja sowieso.