Das mit dem Zählen klappt. Problematisch finde ich, wenn man mehrere gleiche Einträge an verschiedenen Stellen ändern möchte und dafür einzelne Einträge erstellt. Dann funktionieren diese in "Summe", weil man die vorangegangenen gepatchten im nächsten "Durchlauf" nicht mehr mitzählen darf, da diese ja nicht mehr enthalten, da bereits geändert. Möchte man jetzt aber einzelne zum testen ein/ausschalten, dann stimmt die darauffolgende Zählung nicht mehr. Besser also, eine absolute Adressierung. Genau dafür sind die neuen zusätzlichen Einträge. Wenn diese nicht funktionieren, dann Fehlerbeschreibung an zum Beispiel mhaeuser
AppleHDA scheint nicht zuverlässig zu laden
- Keksfamilie
- Erledigt
-
-
weil man die vorangegangenen gepatchten im nächsten "Durchlauf" nicht mehr mitzählen darf
man fängt von hinten an. dann passen die zahlen beim nächsten durchgang noch.
-
Das ist schlau.
Aber die Zählerei hätte ein Ende, wenn man direkt adressieren könnte, wie angedacht …
-
Aber die Zählerei hätte ein Ende, wenn man direkt adressieren könnte, wie angedacht …
womit du recht hast..
-
echt spanische Dörfer für mich, über was Ihr Euch da unterhaltet, lach
fakt ist aber, der User hat noch immer kein Audio
Als diese neuen Rechner mit dem vorgesetzten Intel-Device vorm eigentlichen Realtek-Chip erstmalig rauskamen, da war der User fewtarius auf InsanelyMac im Thread https://www.insanelymac.com/forum/topic/311293-applealc-—-dynamic-applehda-patching/ der erste User, der die ersten Lösungen dafür gefunden hat. Damals arbeitete er mit FakePCI.kext und hat eine Device dafür gefixt. Inzwischen sind viele Controller-Patches diesbezüglich in AppleALC eingeflossen, von dessen tatsächliche Funktion ich aber keine Kenntnis habe, auf Grund der fehlenden Hardware hier. Vielleicht ist aber dieser Device-Patch noch immer nötig.
Die entsprechenden Beiträge liegen von der letzen Seite aus gesehen, aber etliche Seiten zurück. Vielleicht mal die Suche im Thread verwenden nach "fewtarius".
Vielleicht auch mal fewtarius dort anschreiben!
-
das war jetzt nur der IRQ-fix quasi zu fuss... wenn man die "komfortablen" cloverhäkchen nicht mehr zur verfügung hat, das ssdttimezeugs nicht funktioniert, und ebenso irgendwie die neue OC-funktion zum gezielten umbenennen in der dsdt auch noch nicht richtig tut (ich guck mir das aber noch mal ganz genau an, vielleicht sass der fehler ja auch vor dem rechner..), man aber trotz allem den patch einbauen muss. also die version "ich schnitz mir dann eben selbst zurecht, was ich brauche"
-
-
und hat auch noch so richtig spass gemacht. war super spannend: recherchieren, überlegen, hoffen, richtig verstanden zu haben, umsetzversuch, erstes kleines erfolgserlebnis.. nächsten schritt recherchieren... und am ende sprach der klapptopf dann tatsächlich. *jubel*
-
Nein, in der System-DSDT tauchen tatsächlich nur Änderungen auf, wie z.B. die IRQ-Patches von Dir, welche tatsächlich die DSDT selbst verändern.
External-SSDT ändern die DSDT nicht, es sei denn der Code ist explizit so geschrieben, was in der Regel so nicht gemacht wird.
Diese geben dem System Zusatz-Info's, welche aber in der System-SSDT nicht auftauchen.
Daher ist es oft schwer erkennbar, oben eine SSDT nun wirklich fruchtet und das tut, was sie tun soll.
Manchmal hilft hier das Ergebnis vom ioreg (IORegistryExplorer).
-
Ah ok. Habe grade gesehen, dass die SSDT-HPET als eigener Table in MaciASL gefunden wird, scheint also zumindest geladen zu werden. Im IORegistryExplorer finde ich das HPET device:
EDIT:
So inzwischen eine ganze Menge schlauer geworden und Audio geht endlich
Die HPET fixes brauche ich mit meiner Platform anscheinend nicht und die IRQs waren nicht das Problem. In meinem Fall reicht es, die PCIID für das HDEF device mithilfe von rehabmans FAKEPCIID.kext zu faken. Habe mit CorptNewts Unterstützung einen Injector Kext für FAKEPCIID gebaut der den oft benutzten Rundumschlag von FAKEPCIID + FAKEPCIID_Intel_HDMI_Audio + fake der device-id in den DeviceProperties etwas eleganter mit weniger bloat löst. Werde dazu morgen noch was ausführlich schreiben um das dokumentiert zu haben Aber jetzt gehts erstmal in die Heia für mich 
-
Ok, dann war mein Verdacht mit der FakePCI schon richtig. Feine Sache, wenn's jetzt geht.
Auf welche ID bist Du nun gegangen?
-
Herzlichen Glückwunsch
Keksfamilie hast Du auch Audio über HDMI hinbekommen? -
So, jetzt kann ich mal in Ruhe tippen
MacPeet 709D0000
asr10 gute Frage... ich habe leider keinen Monitor mit Lautsprechern oder Kopfhörerausgängen
Kanns also überhaupt nicht testenBei Comet Lake wird ja wie schon festgestellt das Audiogerät hinterm PCH "versteckt" und gibt ne Device-ID vom PCH aus. Die kennt MacOS nicht und was der Bauer nicht kennt frisst er nicht
Daher muss also die ID gefaked werden. Da reicht es aber nicht, das über die DeviceProperties zu machen, ich zitiere CorpNewt:ZitatWhen you fake a device-id in DeviceProperties, it fakes it "at the surface" - i.e. it can be used to get another kext to load by matching an existing IOPCIMatch within the target kext
Sometimes there are further checks within the kext though - which would either need to be patched, or worked around.
Daher ist der Weg, der ganz oft zu finden ist, die ID auf einem "tieferen" Level zu faken, das geht mithilfe des FakePCIID.kext von RehabMan. Das alleine tut erstmal nichts, bietet aber eine Schnittstelle an die man sich mit anderen kexts hängen kann. Da gibts z.B. den bekannten FakePCIID_Intel_HDMI_Audio.kext. Dieser matched auf verschiedene IOKitPersonalities:
und injected dann entsprechend die gefakte ID.
Das matchen auf die IOKitPersonalities klappt halt bei Comet Lake (und anderen neuen Plattformen dann wohl auch) nicht, weil die natürlich andere IDs haben.
Nun gehen dann viele hin, setzen eine device-id in den DeviceProperties wie z.B. 70A10000 (wäre im Bild die zweite), was dann dafür sorgt, dass die IOKitPersonality im FakePCIID matched, damit dann wieder eine device-id gefaked werden kann
Doppelt gemoppelt. Man kann das ganze dann etwas sauberer machen, in dem man keine DeviceProperty nutzt um die device-id zu faken, sondern einen kext baut, der direkt auf die vanilla/originale device-id matched.Als Template kann man einen der vorhandenen IOKitPersonality Einträge nehmen, alle anderen rauslöschen (werden ja nicht benötigt) und dann IDs austauschen.
In meinem Fall habe ich folgendes als Vorlage genommen, meine vanilla device-id war die c8060000:
Alles anzeigenCode- <key>Intel HDMI Audio - 100-series 0xa170</key>
- <dict>
- <key>CFBundleIdentifier</key>
- <string>org.rehabman.driver.FakePCIID</string>
- <key>IOClass</key>
- <string>FakePCIID</string>
- <key>IOMatchCategory</key>
- <string>FakePCIID</string>
- <key>IOPCIPrimaryMatch</key>
- <string>0xa1708086</string>
- <key>IOProviderClass</key>
- <string>IOPCIDevice</string>
- <key>FakeProperties</key>
- <dict>
- <key>RM,device-id</key>
- <data>cJ0AAA==</data>
- </dict>
- </dict>
und geändert in:
Alles anzeigenCode- <key>Intel CML PCH (device-id c8060000)</key>
- <dict>
- <key>CFBundleIdentifier</key>
- <string>org.rehabman.driver.FakePCIID</string>
- <key>IOClass</key>
- <string>FakePCIID</string>
- <key>IOMatchCategory</key>
- <string>FakePCIID</string>
- <key>IOPCIPrimaryMatch</key>
- <string>0x06c88086</string>
- <key>IOProviderClass</key>
- <string>IOPCIDevice</string>
- <key>FakeProperties</key>
- <dict>
- <key>RM,device-id</key>
- <data>cJ0AAA==</data>
- </dict>
- </dict>
cJ0AAA== entspricht der id 709d0000.
Bei dem IOPCIPrimaryMatch dran denken, dass der Vendor mit in den String kommt (weil Intel hier 8086) und die byte-order einhalten.
Die beiden Kexts dann nicht vergessen in der OC Config zu aktivieren
Ich hoffe ich habe das jetzt so alles korrekt wiedergegeben, ist eigentlich kein Hexenwerk.
-
Klingt sehr interessant. Insbesondere als ich Intel HDMI Audio gelesen habe, wurden meine Augen groß: Mein Problem ist, dass ich zwar unter BigSur von Anfang an Ton an den Ausgängen, aber nicht über HDMI hatte; letzteres erst, wenn ich ein 2. Anzeigegerät angeschlossen habe - erst dann wird ein 2. sound device "Intel Kabylake HDMI" im Hackintool angezeigt.
Da ich auch das Comet Lake PCH cAVS (0x06C8) Problem habe, hatte ich gerade Deinen Weg gerade ausprobiert, leider ohne Erfolg.
Vielleicht - falls Du magst, kannst Du ja mal einen TV über HDMI anschließen und die Tonausgabe überprüfen. Bei nur einer iGPU haben auch andere mit Gigabyte und MSI z490 boards das Problem.
-
MacPeet 709D0000
ja, schon klar, dies ist die DeviceID für den Fake, ich meinte aber die dann verwendete layoutID, welche Du mit AppleALC injectest und ob dann alle Geräte des Onboard-Audio's arbeiten.
Seine Beschreibung bezieht sich aber auf den Fake des Onboard-Audio-Chip's, auch wenn er hier einen Intel HDMI Eintrag im FakePCIID.kext dafür missbraucht. Hatte man natürlich auch duplizieren können, somit als Ergänzung.
Wenn Du auf dem 2. Anzeigegerät HDMI-Audio bekommst, dann ist dieser Anschluss vermutlich richtig konfiguriert, der erste Anschluss scheinbar nicht, wo Du kein HDMI-Audio bekommst.
Was zeigt Hackintool denn bei Sektion Patch im Tab Connectors ?
-
MacPeet mein Problem ist hier
Kein Ton über HDMI via iGPU (Asrock z490 PGITX/TB3 u.a.)
Ich war hier gespannt, weil Chipsatz und solo iGPU zu meinem Problem passen und dieses wohl nicht bei Leuten mit dGPU und/oder mehreren Displays auftritt.
-
-
prima, aber es beantwortet noch nicht meine Frage, ob alle Geräte (Outputs/Inputs) nun gehen.
ist auch ein völlig anderer Rechner: Asrock Z490 Onboard-Audio ALC1220 vs. MSI Z490-A Pro Onboard-Audio ALC892
jeder Hersteller kocht seine eigene Suppe
Habe mir Deinen Link zu Deinem Thread angesehen.
Du verwendest Adapter USB-C auf HDMI, die dies vermutlich nicht liefern können. Nicht jeder Adapter ist dafür ausgelegt.
Damit kannst Du die Fehlerquelle nicht finden.
Ferner, unter BigSur zeigt Hackintool selbst auf meinem M1 Mini die Connectors als DP an und nicht als HDMI, obwohl HDMI-Anschluss ja vorhanden ist.
Vielleicht solltest Du die Anschlüsse laut Deinem Bild im Thread mit HDMI mal auf DP patchen, bringt aber nix, wenn der Adapter HDMI-Audio gar nicht unterstützt.
-
MacPeet lieben Dank für Dein Feedback. Vielleicht sollten wir in meinem thread weiterschreiben, soweit es um Ton via HDMI geht.
Aber um kurz zu antworten: Ja, ALC ist anders, aber sitzt, soweit ich das verstanden habe, doch auch hinter einem Intel Gerät. Ich hab ein normales HDMI Kabel an ein Display geschlossen. Hackintool zeigt nur den ALC an, gleichwie ich den framebuffer konfiguriere. Erst wenn ich eine weitere Videoverbindung dazu schalte - also bei mir ein usb-c zu HDMI Kabel, erscheint ein zweites (Intel Kabylake HDMI) device und ich kann dann sowohl über das HDMI Kabel, also auch über den usb-c Adapter Ton ausgeben. In englischen Foren wird neben dem HDMI Kabel ein zusätzliches DP Kabel benötigt, also auch zwei Anschlüsse. Ich hab zwar kein DP Kabel, gehe aber davon aus, dass es analog zu den anderen Berichten und meinem usb-c Adapter läuft. Ich kann dann auch eine Verbindung kappen und immer noch Ton ausgeben, je nachdem über HDMI oder den Adapter...bis zum nächsten Neustart.
