SPDIF Audio unter 13.2 mit OC 0.8.8 auf Gigabyte Z490 Gaming X

hallo PSI69 ,

was frickelei angeht- ob das z.b. durch eintrag, faken/hinzufügen einer id geht wäre vielleicht was- fällt dann aber wie erwähnt in den bereich frickelei. meinst du mit source jetzt inhalt ala *.plist oder tasächlich quellcode für xcode/ usw.?

lg

hm, versuche doch da etwas im bereich "kernel"- "minkernel" "maxkernel" , via der opencoreauxilary tools zu machen, also quasi direkt bei dem dir alten vorliegenden applealc 178er kext. sprich einfügen und positionieren wie gehabt und dann z.b. dort unter min kernel 19.9.9 eintragen -vielleicht bringt das ja etwas

unter releases - https://github.com/ic005k/OCAuxiliaryTools

lg

Nein, diesen Block von da oben einfügen reicht natürlich nicht.

Ich bin aktuell unterwegs und die nötigen Daten habe ich zu Hause auf dem Rechner.

Ich mache es Dir nächste Woche fertig und melde mich dann.

So, bin wieder zu Hause und habe somit Zugriff auf die Daten Deiner Trial-ID.

Wenn Du selbst versuchen willst mit dem aktuellen SourceCode Lilu und AppleALC, dann sind hier die Daten:

Dateien.zip

Im SourceCode von AppleALC ist für Dich nur der Resources-Ordner relevant.

Hier gibt es die Datei PinConfigs.kext und innerhalb davon gibt es eine Info.plist. In dieser ist Deine PinConfig aktuell bei der Position 462 von mir hinzugefügt worden. Schau Dir dies mal an, damit Du alles verstehst.

Ferner musst Du noch im Ordner ALCS1200A die layout15.xml und Platforms15.xml hinzufügen und in der dortigen Info.plist die ID 15 natürlich eintragen. Bei den Dateien oben habe ich dies schon gemacht, brauchst die Dateien im SourceCode nur ersetzen und neu bauen, fertig.

Falls es nicht klappt, Ich habe mal fertig gebaut für Deinen Test mit Ventura.

Archiv.zip

Ja, mach in Ruhe!

Alle bekommen Corona, komisch, ich hatte es noch nicht einmal, aber das Virus hat ja sicher seinen eigenen Stolz.

Ich lege mir die Dateien vom SourceCode Lilu und AppleALC immer in einen Ordner auf dem Desktop.

Dann musst Du auf der Entwicklerseite noch die MacKernelSDK-master laden und entpacken. Hier löschst Du das -master im Namen hinten weg, so dass nur noch MacKernelSDK übrig bleibt.

Diesen ganzen Ordner legst Du auch in den Ordner, wo die Dateien von Lilu und AppleALC sind.

Dann baust Du zuerst den Lilu.kext mit XCode.

Den fertigen Lilu.kext kopierst Du auch in besagten Ordner, bevor Du AppleALC baust, da AppleALC die Abhängigkeit zu Lilu hat.

Ich hatte Dir oben aber auch das fertige Paket geschickt. Hat dies mit Ventura geklappt?

Schön, dass das fertige Paket geht. Natürlich macht es auch Sinn, dass Du es später auch selbst kannst. Ich war vorhin nicht an meinem Hauptrechner und da hatte ich Xcode nicht drauf. Es sieht bei mir dann so auch, nochmals als Ansicht:

Die nötigen Dateien für Deinen Audio-Patch hast Du ja nun und wenn Du die Sache mit dem Selbstbauen erst einmal drauf hast, dann kannst Du auch noch weiter experimentieren an den Dateien, denn bislang war die ID ja noch nicht ganz perfekt, soweit ich es in Erinnerung habe.

In dem Fall geht es dann auch immer schneller, wenn man den Rechner selbst hat.

Ferner, wenn Du diese Sache erst einmal verstehst, dann lernst Du dadurch auch und kannst in Zukunft vermutlich auch selbst neue Codecs bauen, auch für andere Rechner.

Edit:

Hab ich noch vergessen, gute Besserung! Ich hoffe, dass Eure Corona-Geschichte keine schweren Verläufe oder Folgen mit sich bringt. Daumen drück...

Der aktuelle SourceCode Lilu und AppleALC ist ja immer eine Version weiter, als die aktuellen Release's.

Da sich auch die Lilu ändern kann im SourceCode und die Abhängigkeiten von AppleALC zur Lilu, musst Du natürlich auch die Lilu erst neu bauen mit Xcode.

Dies hatte ich auch geschrieben.

Die Debug-Version Lilu aus dem aktuellen Release passt nur, wenn sich dort nichts geändert hat zum aktuellen SourceCode, bzw. für die Abhängigkeiten, welche AppleALC zur Lilu hat..

Am besten immer beides neu bauen. Lilu baust Du Dir ja nur einmal von diesem aktuellen SourceCode, da Du daran ja kaum was ändern wirst, AppleALC dann bei jeder Deiner künftigen Änderungen/Tests natürlich.

Wir bauen selbst immer nur eine Debug-Version davon für unsere Testzwecke. Release bauen obliegt allein dem Entwickler.

Das spätere Anmelden eines neuen Codecs zum Release ist dann nochmal eine ganz andere Hausnummer, sofern der Codec gut genug für die Allgemeinheit ist.

Ich nutze PlistEditPro und wenn ich Vergleichen möchte, dann öffne ich mir die jeweiligen plist-Dateien in zwei Fenstern nebeneinander mittels dem PlistEditPro.

So mache ich es auch, wenn ich von OC- zu neuerer OC-Version gehe. Ich mag diese Tool nicht so.

Schön, dass Dein Versuch mit Xcode nun geklappt hat, der Rest kommt mit der Zeit, je öfter man es macht.

Wenn Du Fragen hast zur PinConfig oder den XML-Dateien, dann musst Du Dich melden.