Probleme beim Batteriebetrieb mit Sound u.a.

Klingt ja schon mal ganz gut und dass trotz der Wake-Einträge die Sache nach Sleep nicht ganz klappt, ist jetzt auch nicht so ganz neu. Einige Geräte, bzw. User mussten dafür tatsächlich zum CodecCommander greifen, aber auch dafür kann ich nichts garantieren.

Jede Kiste reagiert hier anders, nach Sleep.

Natürlich könnte ich Dir auch noch einen ManualMode basteln, anhand der neuen Erkenntnisse.

Die restlichen Angaben, bzw. Hinweise haben sich durch das positive Ergebnis eigentlich erledigt.

Für ein evtl. brauchbaren pull request in die AppleALC bräuchte ich nun aber noch einige Aussagen, in der Annahme, dass die Kiste eine Kombi-Klinken-Buchse hat...

Bei ID 14 switchen ja nur die Outputs, Du musst somit zwischen den Mic's noch umschalten. Welche Geräte funktionieren hier Fehlerfrei (Speaker, Kopfhörer, int. Mic, ext. Mic / Kopfhörer ohne Rauschen?)?

Bei ID 16 switchen die In- und Outputs, Du musst somit nicht manuell umschalten. Welche Geräte funktionieren hier Fehlerfrei (Speaker, Kopfhörer, int. Mic, ext. Mic / Kopfhörer ohne Rauschen?)?

Ich hatte in der letzten Testversion bei 14 und 16 Einträge wie AmpPostDelay, AmpPreDelay und VREF rausgenommen. Ich konfiguriere sowas ohnehin nie. Scheinbar hat's ja was gebracht.

Heute früh hat ein anderer User ein pull request CX8400 layoutID14 für HP Zbook G5 gesetzt, ggf. müssen wir dann später auf 15, 16 oder sonst was ausweichen.

https://github.com/acidanthera/AppleALC/pull/908/files

Er hat aber alles aus ID12 übernommen, außer dass er Speaker und HP im SwitchMode hat. Auch die AmpPostDelay, AmpPreDelay und VREF-Einträge sind hier drin geblieben.

Er hat nur zusätzlich ein EAPD auf LineIn (ext.Mic) in den Wake-Einträgen gesetzt. In Deinem Dump liegt kein EAPD auf diesem Knoten, aber man könnte es ja mal versuchen, wegen Sleep, aber eigentlich wird EAPD ohnehin nur auf die Outputs gesetzt und angewendet.

Ich warte jetzt erst einmal ab, was Du zum Verhalten der Anschlüsse sagst. Ggf. bastel ich Dir dann z.B. nochmal eine Version im kompletten ManualMode und eine im kompletten SwitchMode, sofern die ID16 positiv ausfällt.

Das klingt doch schon mal Top, aber bedeutet vermutlich auch (Zitat: "Da ich kein Headset mit Mic, also kein externes Mic gerade da habe konnte ich das leider nicht überprüfen"), dass Du ein 3-Pin-Klinkenstecker in die 4-Pin-Kombibuchse steckst.

Ok, die wird ja auch abwärts kompatibel sein, denke ich, da es ja wohl bei Dir gut geht, aber bin da nicht der Experte.

Hast Du wegen Sleep nochmal CodecCommander versucht?

Was soll ich nun machen? Nochmal zusätzlich eine Testversion ManualMode entwickeln, wegen Deinem Audio nach Sleep Problem?

Ich mache nur ungern ein pull request in die AppleALC, wenn es nicht wirklich perfekt für alle ist. Bislang ist die ID16 wohl perfekt, solange man nicht in den Sleep geht.

Ok, vielleicht bekommen wir das Sleep-Problem nicht hin, aber mit dem Audio im Akku-Betrieb hatten wir ja schon zumindest mal Erfolg.

Ich bin auch nicht der große Sleep-Experte, hatte es auf Hackintosh sogar immer gemieden (außer auf meinem T450s, welcher perfekt lief), da es früher schon viele negative Meldungen gab.

Falsches Sleep kann auch zu Hardware-Schäden bei Speicher/RAM oder bei SSD/HDD führen, dazu gab's früher Meldungen genug.

Wie ist eigentlich das Sleep/Audio-Verhalten im Netzbetrieb? Gibt es da Unterschiede zum Akku-Betrieb?

Bezüglich CodecCommander (hab ich selbst nie gebraucht), habe ich schon oft in den Kext selbst reingeschaut, da so viele verschieden Versionen im Netz im Umlauf sind.

Schick mir einfach mal Deinen Kext zu, gern auch per PN. Ich schau mal rein, denn auch hier müssen die Knoten zum Aufwecken explizit angegeben werden.

So, ich hab Dir nochmal eine Test-Version erstellt, bevor wir die Sache in der AppleALC dingfest machen.

Diesmal habe ich in der ursprünglichen ID12 Deine PinConfig aus dem Dump eingetragen, ohne weitere Änderungen. Damit will ich nur sehen, ob die Rausnahme der anderen Einträge tatsächlich eine Relevanz hat, bezüglich Ausfall im Akku-Betrieb.

Diesmal auf ID15 habe ich Dir nochmal einen ManualMode erstellt und hierbei den LineIn noch in dem Wake aufgenommen.

In ID16 ist der SwitchMode wie gehabt, aber auch hier zusätzlich den Wake auf LineIn.

Edit: Datei gelöscht, siehe unten

Teste mal alles in Ruhe durch, eilt ja nicht.

Edit:

Nur mal so am Rande, betreffs des Nutzers, welcher kürzlich den pull request CX8400 ID14 gesetzt hat, der hat auch Probleme. Frage mich nur, warum er dann ein pull request setzt, wenn's doch Probleme gibt.

...er hat nun auch mal meine Trial getestet. Bei ID15 hatte ich ja einen Fehler drin, aber 16 konnte er testen. Bei ihm taucht im Switch das externe Mic nie auf, vermutlich hat er ein 4-Pin-Headset.

Hast Du auch keine kabelgebundenen Apple-Kopfhörer, denn die haben ja 4-Pin. Wäre schön, wenn wir dies auch testen könnten, bevor wir was halb-fertiges zum Release geben.

Edit:

Ich habe die Testversion nochmals eingespielt, da ich einen Schreibfehler beim Wechsel von ID14 auf 15 hatte.

Archiv.zip

Ok, dann muss ich ggf. den Wake-Eintrag auf dem Input wieder entnehmen.

Bei der Test-Version mit ID14 und 16 geht es aber nach wie vor?

Edit:

In dem CodecCommander ist kein Device für CX8400 konfiguriert. Ich muss mir dies mal genauer ansehen, wie es hierbei gemacht wird.

Ich habe mal die letzten Änderungen raus genommen. Sollte jetzt mit 15 ManualMode wieder gehen und mit 16 auch, bis auf das zurück zu Speaker-Problem.

Du kannst auch gern mal Bilder machen, wie die Geräte (Output/Input) im System/Audio angezeigt werden.

Der User auf Insanely schrieb, dass bei Ihm nie ein Kopfhörer angezeigt wird, weder im Manaulmode, noch im Switch, aber er hat auch einen G5.

Bei Dir wird im Switch beim Stecken doch aber der Wechsel von Speaker auf Kopfhörer angezeigt, oder?

Mit dem ManualMode solltest Du nun wieder zurück aktivieren können, hoffe ich.

Der Ton bei Akku sollte nun auch wieder bleiben, ist ja quasi wieder der Stand, den wir schon hatten, nur dass ich auf 15 gewechselt habe, statt der 14.

Archiv.zip

Das ist doch super, dann brauchen wir nicht mehr experimentieren.

Somit hat er doch einiges richtig gemacht. Sein pull request wird ja im nächsten Release AppleALC drin sein.

Er hat ja auch die Outputs im SwitchMode und Dein Problem war, dass Du nach Stecken und Entfernen der Kopfhörer nicht zu Speaker zurück kommst. Geht dies mit seiner Version auch?

Als Manko verbleibt eigentlich nur, dass Du kein 4-Pin Headset hast, somit ext. Mic nicht Testen kannst.

Ist so zumindest für Dich sehr gut nutzbar, denke ich.

Die Probleme betreffs Kombibuchse hat er ja wohl auch noch, hat die Inputs ja noch Manual gelassen, somit müsste ohnehin manuell umgeschaltet werden.

In der AppleALC sind aber auch ganz viele ID's für unterschiedliche Geräte, welche betreffs Kombibuchse nicht perfekt sind, was aber auch bekannt ist.

Entweder gibt's Rauschen auf den Kopfhörern oder/und ext. Mic geht nicht.

Heutzutage stellt sich aber auch die Frage, ob die Kombibuchse überhaupt noch so wichtig ist, da ja heute schon fast jeder mit BT-Kopfhörern arbeitet.

Ich hatte auf meinem Lenovo auch Probleme mit der Kombibuchse, im SwitchMode nur Rauschen. Dann hatte ich mir damals einen ManualMode entwickelt, wo tatsächlich alles ging, aber verwendet hatte ich es dann nie, was die Kombibuchse betrifft.

Ich hatte immer nur die Apple-Airpods verwendet, welche keinen Patch brauchten.

Falls Du noch Bock und Zeit hast, kannst ja nochmal testen. Ich habe beim SwitchMode ID16 nochmal was verändert auf Basis seiner ID14. Die ID14 ist hier wie seine, die ID16 auf seiner Basis, aber mit kleiner Änderung bei den Inputs im SwitchMode.

Archiv_ID14_16.zip

Zitat von iPhoneTruth

Aber rein kommt dabei nur Rauschen.

Hab ich mir schon gedacht, dass es so geht. Rauschen meinst Du jetzt bei dem Input, bzw. bei der Audio-Aufnahme? Nicht auf den Kopfhörern?

Wenn's der Input ist, dann müsste man die Boost-Einstellungen mal runter setzen, bzw. ganz entfernen.

Es hat sich eingebürgert, dass die User immer auf beiden Mic's einen Boost 3 setzen, was oft nicht nötig ist. Bei einigen Rechnern ist es sogar schlecht. Hier müsste man den Pegel wieder extrem runter drehen.

Man kann die Input's eigentlich ganz einfach mittels Siri auf dem Rechner testen, da Siri extrem empfindlich ist, verlangt eine absolut klare Stimme.

Wenn Siri schlecht versteht und die Befehle ständig anmeckert, dann ist Boost zu hoch, was man auf 2 oder 1 runter schrauben kann, bzw. ganz entfernen kann.

Kannst Dein internes und externes Mic ja mal mit Siri testen und ggf. können wir auch noch weiter experimentieren. An mir soll es nicht liegen.

Der Entwickler der ID14 will den Rechner ja verkaufen, macht also nicht weiter.

Edit:

... hat theroadw doch noch getestet und bei ihm läuft jetzt alles perfekt. Er hat die neuen Erkenntnisse übernommen und hat auf GitHub bereits eine neue AppleALC drin.