Probleme beim Batteriebetrieb mit Sound u.a.

hda-gfx Eintrag ist für's HDMI-Audio am externen Monitor-Anschluss, hat mit dieser Sache (internes Onboard-Audio) nichts zu tun

Schlechter Akku-Zustand kann eine Rolle spielen, was ich aber nicht glaube. Es wird an den Power-Settings im Batterie-Betrieb liegen.

CX8400 in AppleALC entwickelt für/von:

ID 12: CX8400 for Elitebook 1050 G1 by tyufhl & kuque

ID 13: Conexant CX11970 (CX8400) for Acer Swift 3 SF313 (Ice Lake) by b0ltun

Beide ID's verwenden unterschiedliche Knoten, daher geht bei Dir nur die ID 12, weil es wohl auch ein Elitebook ist. Der Hersteller Acer verwendet wieder andere Knoten, auch normal, alle Hersteller kochen ihre eigene Suppe, was ja auch ein Grund dafür ist, dass es in der AppleALC so viele unterschiedliche ID's gibt

Beide ID's sind im Manual-Mode konfiguriert, so dass das manuelle Umschalten nötig ist. Dies kann damit zu haben, dass die sogenannte Kombi-Buchse im automatischen SwitchMode oft Störungen auf den Kopfhörern liefert. Das Problem ist bekannt.

Bei noch älteren Geräten mit noch 2 Klinken-Buchsen gab es diese Probleme nie.

Beide ID's sind in der AppleALC ohne WakeConfigData und WakeVerbReinit konfiguriert, was das Audio nach Sleep auch nicht zurück bringt. Evtl. könnte hier der CodecCommander.kext Abhilfe schaffen, sofern es noch eine Version gibt, welche mit Ventura/Sonama geht.

Ich hab das Ding nie selbst versucht, da ich meine ID's immer möglichst perfekt entwickelt habe, so dass ich CodecCommander nie brauchte.

Fazit:

Überprüfe mal die Power-Einstellungen! Du schreibst ja selbst, dass am Netzteil alles geht, wobei Du hier vermutlich auch die Sleep-Zeit höher eingestellt hast, bzw. sogar auf immer an.

Betreffs Akku geht er wohl nach 2 Minuten auf Sleep, wenn ich Deine Dateien und Aussagen richtig gedeutet habe und dann ist das Audio weg (Stromsparmodus/abschalten der Geräte), kommt nach Sleep auch nicht automatisch zurück, weil es in AppleALC nicht konfiguriert wurde.

Wie Du in Post#1 beschreibst, durch das Umschalten auf Kopfhörer und anschließend int. Audio wird das Audio wieder erweckt, ist dann aber nach ca. 2 Minuten wieder weg, unter Akku-Betrieb. Klingt sehr nach den Power-Settings unter macOS bei Akku-Betrieb.

Bei Windows hast Du diese Probleme natürlich nicht, wäre ja auch schlimm, wenn es so wäre.

Ich hatte ja oben auch geschrieben, dass ich nicht glaube, dass es am Akku liegt.

Ok, noch vor Sleep im laufenden Betrieb nach 2 bis 3 Minuten bricht das Audio weg, habe ich verstanden.

Dieses Problem kenne ich nur von damals mit einigen Core2Duo's oder -Quad-CPU's, wo das CPU-Frequenz-Timing schrittweise runter gesetzt werden musste, bis das Audio stabil lief.

Der erste alte Rechner in meiner Signatur hatte auch genau dieses Problem, wo ich genau dies angewendet habe, allerdings hierbei noch mit Clover.

Es kann also am CPU-PowerManagement liegen.

Hierbei fällt in Deiner EFI auf, dass Du im ACPI-Bereich SSDT-PLUG.aml hast und auch aktiviert hast. Eigentlich reicht dies völlig aus für einen Laptop.

Zusätzlich hast Du aber auch CPUFriend.kext und CPUFriendDataProvider.kext aktiviert. Braucht er diese Kext's denn überhaupt? Wenn der cf-frequency-data-Wert im CPUFriendDataProvider.kext nicht richtig ist, dann kann es schon gut sein, dass was klemmt.

Boote doch mal bitte mit CPUFriend.kext und CPUFriendDataProvider.kext auf NO stellen in der config.plist und dann mal das Audio testen. Dient letztlich nur dem Ausschlussverfahren, um vielleicht die Ursache zu finden.

Ich habe mir auf GitHub mal die ganzen OC-EFI's zu den diversen HP-Laptops angeschaut und dort verwenden alle nur die SSDT-PLUG.aml vom OC, aber keiner verwendet CPUFriend.kext und CPUFriendDataProvider.kext.

Hat vermutlich mit den Einstellungen Stromsparmodus, bzw. lowpowermode zu tun, wobei diese Dinge natürlich für einen realMac entwickelt wurden, welcher damit natürlich keine Probleme hat.

Hier geht es aber nun um einen Hackintosh, somit sind die Dinge ganz oft anders.

Hier mal Dein Bild von oben. Stelle mal, wenn möglich den Stromsparmodus auch bei Batterie auf aus. Der Stromsparmodus reduziert, bzw. schaltet Geräte mit hohem Stromverbrauch ganz aus, in der Grundeinstellung passiert es ab 2 Minuten im Akku-Betrieb, was Deiner Beschreibung entspricht und ist auf meinem real MacBook nicht anders.

Wenn er im Batterie-Betrieb das Audio verliert, mal bitte Klick, bzw. rechts Klick auf's Batteriesymbol, ob der lowpowermode on ist:

dazu noch weiter:

Auf dem realMac sicher kein Problem, auf dem Hacki kann diese Reduzierung natürlich dazu führen, dass das CPU-Timing/Bustakt kippt und das Audio bricht.

Da im Netzbetrieb alles super geht, kann es nur irgendwo hierbei liegen.

Schade, aber dann gehen auch mir leider die Ideen aus.

Hatte ich Dir ja in Post#4 bereits geschrieben, allerdings sind diese Einträge dafür da, um das Audio nach Sleep wieder zu aktivieren, gleiches macht der CodecCommander.kext, falls diese Einträge fehlen.

Allerdings bricht bei Dir das Audio ja bereits vor Sleep und auch nur im Akku-Betrieb. Von da her, glaub ich nicht, dass es daran liegt.

Edit:

Ich habe Dir mal eine Testversion gebaut. Hierbei habe ich bei Layout-ID 12 die Wake-Einträge eingefügt.

Zusätzlich habe ich eine Layout-ID 14 entwickelt, welche im Switch-Mode, ohne manuelles Umschalten gehen sollte.

Es kann sein, dass Du beim ID-Wechsel beim Booten ein nvram-reset machen musst, je nach Deinen Einstellungen in der config.

Archiv.zip

Beide Kext's tauschen und dann mit ID 12 und 14 testen!

Ok, na immerhin geht es auch mit dem SwitchMode, ist ja schon mal ein Gewinn. Betreffs der Wake-Einträge hatte ich ja eingangs schon vermutet, dass das Problem nicht hier liegt, betreffs Audio-Verlust im Akku-Betrieb.

Nein, in der DSDT oder SSDT wird nur das Device selbst zur Verfügung gestellt, da kannst Du keine Parameter übergeben.

Auf früheren Rechnern war das Audio-Device immer HDEF, bei neueren Rechnern war es dann HDAS, was damals noch für macOS von HDAS to HDEF gepatcht werden musste, aber inzwischen kann AppleALC auch mit HDAS umgehen.

Die Konfiguration des Audio-Chips erfolgt unter Windows mittels Hardware-Treiber, unter Linux mittels ALSA-Treiber und unter macOS in der AppleALC. Früher wurde dafür die AppleHDA selbst gepatcht, als es AppleALC noch nicht gab.

Informationen betreffs der Verknotung des Audio-Chips bekommst Du mittels Codec-Dump unter einer Linux-Live-Version im Terminal:

Dort werden dann mehrere Dateien erzeugt.

Konfiguriert wird das Audio dann im SourceCode der AppleALC im Resources-Ordner. Hierbei für Dich relevant ist PinConfigs.kext und die Dateien im CX8400-Ordner.

Sorry, ich war 'ne Woche im Urlaub.

Ich schaue mir den Dump noch genauer an, aber ich kann auch nicht sagen, warum dies im Akku-Modus passiert.

Grundlegend sind die Knoten gleich, wie bei ID12 und bei der 14, die ich Dir gebastelt habe. Die Anschlüsse selbst funktionieren ja auch.

Von Deinem Dump:

Von aktueller ID12/14:

Schau mal noch auf diese Seite, ob Du da noch was einstellen kannst, betreffs lowpowermode oder andere Seiten per Internetsuche: https://support.apple.com/de-de/101613

Bezüglich VoodooHDA bin ich auch kein großer Freund davon.

Ansonsten bin ich aktuell auch ratlos.

Edit:

Hier erst einmal der gewandelte Dump zur Einsicht: Dump.zip

Auch wenn die Knoten eigentlich identisch sind, habe ich Dir mal was zum Testen, anhand Deines Dump's gebastelt und kleine Änderungen vorgenommen.

ID12: anhand Deiner PinConfig, ansonsten unverändert

ID14: wieder mit Speaker und HP im SwitchMode

ID16: hier zusätzlich auch int. und ext. Mic im SwitchMode

Archiv.zip

Alles mal versuchen, auch bitte im Akkubetrieb den Rechner einmal in den Sleep schicken und schauen, ob's danach auch noch bricht!

Auch mal in Dienstprogramme/Audio-MIDI-Setup schauen!

Ein ioreg vor Wegbrechen und danach kann auch nicht schaden.

Vielleicht ist auch einfach nur Deine EFI noch nicht perfekt. Was ich bei Deiner EFI etwas vermisse, ist sowas wie eine SSDT-BAT.aml und die ganzen BAT-Patches unter ACPI/Patch, (selbst die IRQ-Patches sehe ich nicht wirklich, welche auf Laptops unter macOS ja ein Zwang sind für's Audio, aber da Du ja Audio bekommst, muss dies ja irgendwie passen). Zumindest hatte ich sowas auf meinem Lenovo. Für HP Elite X2 G3 finde ich leider keine EFI zum Abgucken, aber für den G2, welcher auch eine SSDT-BAT.aml und die ganzen BAT-Patches verwendet.

Evtl. liegt hier ja noch das Problem, keine Ahnung. Den neuen Akku hast Du unter Windows kalibriert? Die Anzeige unter macOS in der Menüleiste geht perfekt? ...zeigt die richtigen Prozent an und bei Stecken des Netzteils auch die richtigen Ladezeiten? Stecken des Netzteils und Entfernen dessen wird sauber erkannt in der Menü-Leiste?