AppleHDA scheint nicht zuverlässig zu laden

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

Zitat von apfelnico

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 …

Zitat von apfelnico

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"

grt

ok, verstehe so halbwegs

übrigens, eine mega Arbeit in dem anderen Thread, was ja zu Audio führte. Hier hat Eure FaceTime-Sitzung mal richtig gefruchtet, prima.

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).

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?

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.

Zitat von Keksfamilie

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.

asr10

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.

Keksfamilie

prima, aber es beantwortet noch nicht meine Frage, ob alle Geräte (Outputs/Inputs) nun gehen.

asr10

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.