I hope you don't mind me posting a how does it work question here? I’m trying to understand how the audio hacks fit together on this NUC. I don't have any audio problems, just looking to see how it works.
This is what I understand to be the happening.
1/ Binary patch the native AppleHDA kext as follows, using KextsToPatch:
a) Replace Native ALC262 Codec Id with id for our NUC codec, ALC283
b) Change Resource string, to look for extension zml.zlib instead of xml.zlib
2/ Copy appropriate layout and platforms files for ALC283 to ~AppleHDA.kext/Contents/Resource *.zml.zlib
OK that was the easy bit I think.
3/ ACPI related, ah
a) Rename HDAS to HDEF (ACPI object rename) required by OSX
b) Add SSDT-Config creates RMCF device , sets AUDL to 1 (no audio injection) and FAKH to 1 (HDMI audio related)
c) Add SSDT-HDEF
// inject properties for audio
Method(_SB.PCI0.HDEF._DSM, 4)
{
If (Ones == \RMCF.AUDL) { Return(0) }
I'm trying to understand this line as, I would guess that as we set \RMCF.AUDL to 1 in 3b) , we should just return out of the method at this point? However I see later that we do the following:
{
"layout-id", Buffer(4) { },
"RM,disable_FakePCIID", Ones,
"hda-gfx", Buffer() { "onboard-1" },
"PinConfigurations", Buffer() { },
}
and I’m pretty sure we do this stuff as I experimented with changing values of onboard-1 and the settings altered in IOReg
d) SSDT-NUCHDA
Seems to create RMCF.cache entry with CodecCommander / CodecCommanderProbeInit sections. The later has a LayoutID and PinConfigs which seem to be the real PinConfigs for our Codec
Are these used in preference to the PinConfigurations Data that exists directly under HDEF?
Probably a hundred other questions, but understanding this might jog me along the way a bit.