Beiträge von iPhoneTruth

    Hat bei mir bestens funktioniert. Besten Dank für die sehr gute Anleitung.


    Ich mußte lediglich in Windows 11 für den Befehl "psexec -i -d -s regedit.exe" die einfache "Eingabeaufforderung" als Administrator ausführen. Mit der "Windows PowerShell" als Administrator wollte es nicht klappen. Das als Hinweis für andere, die da vielleicht auch hängenbleiben.

    Ich habe Deine neuen Kexts mal probiert. Nun wird vom Headset, wenn ich dieses einstecke, tatsächlich das Line-in-Microfon angezeigt. Aber rein kommt dabei nur Rauschen.

    Ja, Du hast recht: eigentlich braucht man das Micro vom Headset kaum. Ich komme mit der Variante auf jeden Fall gut zurecht.


    Dir auf jeden Fall ein ganz dickes Lob und herzlichen Dank für Deine Bemühungen.

    :klatschen:

    Das funktioniert auch: nach dem Stecken und Entfernen des Kopfhörers ist der Ton über Speaker wieder da, auch nach einer längeren Ruhepause, z.B. über Nacht, ist der Ton wieder da.

    Und … ich habe ein 4-Pin Headset.

    Da ist allerdings das Problem, daß er das Micro am Headset nicht erkennt. Wie Bild in Post 31, also wie bei Deiner letzten Kext mit ID 15 zeigt die Systemeinstellung Ton beim Eingang nur "Internes Mikrofon" an.

    In der Zwischenzeit habe ich ein Headset mit 4-Pin Klinke!

    Ich habe zunächst mal mit der normalen AppleALC und ID 12 gestartet. Da gab es dann tatsächlich in den Systemeinstellungen "Ton" im Eingang ein "Line-In" Gerät. Was da allerdings "rein" geht ist nicht zu gebrauche, sprich, da kommt gar nichts an und man hört nur Rauschen. Siehe Anhang.


    Mit den neuen Kext und ID 15 gestartet findet sich tatsächlich im Eingang nur das interne Micro und kein Line-In. Siehe Screenshot.


    EDIT: Ich habe von dem anderen User das hier gefunden https://github.com/theroadw/Zbook-G5-17-WX-4170 und die AppleALC.kext heruntergeladen und siehe da, Ton läuft, fällt nicht aus und ist auch nach einem Sleep wieder da! Siehe Anhang.

    Bei der ersten Test-Version mit ID 14 wie auch bei der zweiten Test-Version mit ID 16 bleibt der Ton im Batteriebetrieb (bei der letzten, also der dritten Test-Version eben nicht).

    Allerdings habe ich gerade bei beiden festgestellt, daß der Ton beim automatischen Switch zurück, also von Kopfhörer zu Lautsprecher, leider wegbleibt (ist vielleicht gleichzusetzen mit dem Aufwachen aus Sleep?).

    Jawohl, ich habe ein 3-Pin-Klinkenstecker in die 4-Pin-Kombibuchse gesteckt. Werde mal schauen, daß ich ein 4-Pin-Headset wo auftreibe.


    CodecCommander habe ich noch nicht probiert. Ich war mir da nicht klar, ob ich den einfach hinzufügen kann oder noch was irgendwo eingeben muß. Werde ihn einfach mal hinzufügen und dann berichten.


    EDIT: Ich habe CodecCommander direkt nach AppleALC eingefügt und damit gebootet, doch es hat sich nichts geändert: Ton ist nach Sleep weg.

    ZUDEM ist dann der Ton selbst nach einem Neustart weg! :(

    Ich konnte für ID 14 wie 16 Speaker, Kopfhörer und internes Mic überprüfen. Bei beiden funktionieren die Geräte einwandfrei, auch der Kopfhörer ohne Rauschen. Da ich kein Headset mit Mic, also kein externes Mic gerade da habe konnte ich das leider nicht überprüfen.

    Und Ja, die Kiste hat eine Kombi-Klinken-Buchse.

    Also: Mit ID 14 und ID 16 bleibt der Ton im Batteriebetrieb. Nach Sleep ist der Sound allerdings bei beiden IDs weg, und … nach einem Neustart ist der Ton immer noch weg, auch beim Netzbetrieb. Da ich mit diesen beiden IDs nicht mehr switchen kann zwischen Lautsprecher und Kopfhörer kann ich jetzt auch den Ton nicht mehr wie früher aufwecken.


    :(


    Ich habe die zwei IOREG-Dateien erstellt.


    Nun zu Deinen Fragen bzw. Anregungen:

    Den lowpowermode habe ich schon öfters komplett ausgeschaltet, hat aber nichts gebracht. Andere Möglichkeiten habe ich keine gefunden.


    Meine EFI stammt vom HP Elite X2 G2. Habe diese an das G3 angepasst. In der EFI für das G2 war eine SSDT-BAT.aml mit den entsprechenden Patches drin, die hat allerdings im G3 dazu geführt, daß die Prozente nicht richtig dargestellt wurden. Ohne diese SSDT und die Patches läuft der Akku bisher normal und alles rund um die Batterie funktioniert eigentlich.

    Ich habe den Akku bisher hauptsächlich in macOS verwendet, auch ein paar Mal ganz entladen und dann wieder voll aufgeladen sprich kalibriert.
    Was nicht exakt angezeigt wird ist die Zeit, wie lange er noch braucht für die volle Aufladung, da wird aktuell mehr angezeigt als er wirklich braucht.

    Möglicherweise könnte eine SSDT-BAT.aml für das G3 hier eine Verbesserung bringen, ein Bisschen habe ich da auch schon rumgebastelt, aber bisher noch nicht so ganz durchgeblickt, was ich da ändern, patchen oder anpassen könnte oder sollt.

    MacPeet Siehst Du eine Möglichkeit, wie man das Problem noch hinbekommen könnte?


    D.h. hat es überhaupt einen Sinn, einen neues LayoutID für AppleALC zu erstellen? Ich habe mir den Guide dazu mal angeschaut (https://github.com/5T33Z0/Appl…e/main/AppleALC_Layout-ID), aber für mich ist das ein Buch mit sieben Siegeln.


    Oder liegt das Problem vielleicht gar nicht an AppleALC sondern am Energiemanagement? Wie könnte man das aber steuern?


    Ich habe mal VoodooHDA installiert, da läuft der Ton auch im Batteriebetrieb, aber dazu muß man die SIP abschalten, und einen Systemabsturz mit VoodooHDA hatte ich auch schon. Damit will ich auf Dauer lieber nicht arbeiten.

    Gäbe es vielleicht eine Möglichkeit, aus der DSDT.aml das Audio-Device auszulesen und mit einer SSDT-HDEF.aml gewisse Parameter zu ändern?


    Ich füge mal die DSDT.dsl Datei an. Wenn ich das richtig sehe und verstanden habe, dann findet sich das Audiogerät in dem Device (HDAS).

    Dateien

    • DSDT.dsl

      (1,16 MB, 35 Mal heruntergeladen, zuletzt: )

    Besten Dank für die Arbeit und die Testkexts.


    Ich konnte das nun überprüfen. Das Ergebnis: Der Switch-Mode funktioniert damit. Er erkennt, wenn ich den Kopfhörer einstecke und wenn nicht und schaltet automatisch um.

    Allerdings bleibt es dabei, daß er im Batteriebetrieb den Ton verliert, sowohl mit der ID 12 wie mit der ID 14. Leider!

    Mit CPUFriend.kext und CPUFriendDataProvider.kext habe ich nur etwas herumgespielt und dachte, daß ich damit etwas steuern kann. Der Rechner lief und läuft nun aber auch genauso gut ohne diese zwei Kext, allerdings nach wie vor mit dem Tonproblem im Batteriebetrieb.

    Ich habe gerade auch mal aus dem Batteriezustand (d.h. aus dem Zustand "kein Ton") das Netzgerät angesteckt und siehe da, der Ton ist sofort wieder da!

    Meines Erachtens muß es darum tatsächlich eine Sache des CPU-Power-Manegements sein. Nur wie da dran zu schrauben ist, das weiß ich nicht …