AppleHDA Realtek Audio [Guide]

[toleda]

set to as long as "InjectKexts" under "Custom" is set to "Detect" AND FakeSMC.kext is in either /S/L/E or present in "KerrnelCache" When these conditions are met kexts present in "Clover/Kexts/other" will not be loaded.

The Wiki says "Kexts from /EFI/CLOVER/kexts/ will be injected only if FakeSMC is not present in the kernelcache"
No mention of the location of FakeSMC.kext
Your conclusion is not consistent with the stated Clover behavior.

 

[Henties]

Hi @toleda Thank you for your response, but sorry I am still confused because combining what the WiKi says about "Detect" under SystemParameter with that what the WiKi says about "Detect" under Cusom > Custom Entries, made me arrive at my conclusion or rather interpretation.

Here are both entries of the WiKi.

Quote
SystemParameters

Detect - Kexts from /EFI/CLOVER/kexts/ will be injected only if FakeSMC is not present in the kernelcache

In case Custom Entries are defined, its own InjectKexts key will override this global one.

Custom

If the automatically scan entries are not enough you can add your own custom boot entries.

Custom Entries

InjectKexts - Inject kexts. Valid options are Yes, No or Detect.

Use Detect to inject kexts only if FakeSMC is not present in KernelCache or /S/L/E.

For OSX, OSXInstaller and OSXRecovery type entries.
End Quote

Here my revised interpretation of the quoted WiKi explanations.

SystemParameters
I interpret this to mean that if your script changes "Detect" to "Yes" under SystemParameters, which it does once it has been run, then that "InjectKexts Yes" means to me that whether FakeSMC is present in KernelCache or not, kexts will be INJECTED from /Clover/Kexts/other and Kexts in KernelCache, that are also present in Clover/Kexts/other, will be IGNORED, which seems
to be undesirable for a Skylake High Sierra build.

CustomEntries
If one now uses "InjectKext Detect" under Custom Entries to override the "Yes" from your script
under SystemParameters, then all kexts present in /Clover/Kexts/other, will now be IGNORED and kexts will be loaded from KernelCache provided FakeSMC is present in KernelCache or /S/L/E.

Now what happens to the realtekALC.kext which your script places into Clover/Kexts/other and when "InjectKexts Detect" is also set under CustomEntries?

In my case, unless I place/move realtekALC.kext into /L/E with Kextbeast and subsequently update the KernelCache with "sudo kextcache -i /" I have no functioning audio.

Summary.
Using "InjectKexts Detect" under "CustomEntries" and copying realtekALC.kext to /L/E and therafter run "sudo kextcache -i /" I end up with a system with fully working audio and the assurance that kexts are always loaded from KernelCache during each time the computer is rebooted, no matter what your "audio_cloverALC-130_v0.4.command" applies as a parameter for "InjectKexts" under SystemParameters.

Kindly check this because my interpretation may still be lopsided.

Thanks Henties

 

[toleda]

combining what the WiKi says about "Detect" under SystemParameter with that what the WiKi says about "Detect" under Custom > Custom Entries, made me arrive at my conclusion

I don't believe Clover handles the same property in different ways. The question: does Clover check for S/L/E/FakeSMC.kext. The answer, Clover does not/cannot check anything in S/L/E. Clover has finished when the User selects the partition (/S/L/E) to "boot."

The statement/GUI/Custom:"... if FakeSMC is not present in KernelCache or /S/L/E. " is not valid.
Valid/SystemParameter: "... if FakeSMC is not present in the kernelcache."

Valid and correct: "... if FakeSMC is not present in the kextcache."

 

[Henties]

I don't believe Clover handles the same property in different ways. The question: does Clover check for S/L/E/FakeSMC.kext. The answer, Clover does not/cannot check anything in S/L/E. Clover has finished when the User selects the partition (/S/L/E) to "boot."

The statement/GUI/Custom:"... if FakeSMC is not present in KernelCache or /S/L/E. " is not valid.
Valid/SystemParameter: "... if FakeSMC is not present in the kernelcache."

Valid and correct: "... if FakeSMC is not present in the kextcache."

Hi @toleda Thank you for your explanation with which I can completely identify myself. What this boils down to is that one should not rely upon what the Clover WiKi is trying to convey to the user that wants to broaden his knowledge/horizon Sad state of affairs indeed.

My original problem is however not solved yet, even though I now totally agree with your statement "Valid/SystemParameter: "... if FakeSMC is not present in the kernelcache."

We can thus have a number of scenarios, that compels me to adjust my original interpretation and or understanding as follows:

FakeSMC not present in kernelcache.
To me this means that kexts will be loaded from "/Clover/Kexts/other" irrespective of whether the "InjectKexts" parameter is set to "Yes" or "Detect". Duplicate kexts that are also in kernelcache will be ignored.

FakeSMC present in kernelcache. "InjectKexts Yes"
To me this means that kexts will be loaded from "/Clover/Kexts/other" when the "InjectKexts" parameter is set to "Yes". Duplicate kexts that are also in kernelcache will be ignored.

FakeSMC present in kernelcache. "InjectKexts Detect"
To me this means that kexts will be loaded from kernelcache when the "InjectKexts" parameter is set to "Detect" Duplicate kexts that are also in "/Clover/Kexts/other" will be ignored.

The original problem revisited:
Provided my above interpretations are correct now, and it is my intention to load all my kexts from kernelcache, after having ascertained that FakeSMC is indeed present in kernelcache and "injectKexts was verified to be set to "Detect" I am ready to go. FakeSMC, Lilu, shiki, realtekALC as well as nvidiagraphicsfixup kexts, that are all in kernelcache as well as in /Clover/Kexts/other, will be loaded from kernelcache, the duplicate kexts in /Clover/Kextx/other will be ignored.

When I now run the "audio_cloverALC-130_v0.4.command" script, the hard coded "injectKexts Yes" of that script overrides my "InjectKexts Detect", to "Yes". During the reboot, after the script completed its routines, all kexts will now be loaded from /Clover/Kexts/other and the duplicates in kernelcache will be ignored. For Skylake
in combination with High Sierra an undesirable situation.

To prevent that happening I reset the "InjectKexts" parameter from the scripts's "Yes" to "Detect" , and with Kextbeast copy the newly generated realtekALC.kext to /L/E then run "sudo kextcache -i /" to get the cache updated after the copy operation. Only when I completed all that after your script in turn completed its routines will I restart the computer with the knowledge that kexts will indeed now be loaded from kernelcache.

I can off cause circumvent all the extra steps I am applying after your script has completed running, by just modifying your script and that is then dusted and done with, but I am also considering many other users that are suffering from "Random reboots" during and after sleep, which appears to be related to kexts not being loaded from kernelcache. My random reboots and system lockups, during or immediately after waking from sleep, seem to have vanished after I started applying the extra steps I eluded upon, earlier.
@RehabMan is also advising users that ask him for assistance in resolving the random reboot lockup problem during and shortly after sleep, to set "injectKexts" to "Detect"
I subsequently also adopted @RehabMan 's advice which seemed to fix the sleep problem with my rig, albeit only temporarily, and until I discovered that my "InjectKext Detect" gets overridden by the "audio_cloverALC-130_v0.4.command" script.
Presently my rig has been sleeping for just over 2 days without any sleep problems, a period already longer than I am used to.

Once again I would appreciate your valued comments.

Thanks Henties

 

[toleda]

FakeSMC present in kernelcache. "InjectKexts Yes"
To me this means that kexts will be loaded from "/Clover/Kexts/other" when the "InjectKexts" parameter is set to "Yes".

FakeSMC present in kernelcache. "InjectKexts Detect"
To me this means that kexts will be loaded from kernelcache when the "InjectKexts" parameter is set to "Detect"

Not correct.
EFI/CLOVER/kexts are not in kextcache (not kernelcache).

If FakeSMC.kext is in EFI/CLOVER/kexts/..., it will not be in kextcache.
InjectKexts/Yes tells Clover to inject EFI/CLOVER/kexts/...
InjectKexts/Detect tells Clover to ignore EFI/CLOVER/kexts/...

EFI/CLOVER/kexts/Other/FakeSMC.kext is a valid configuration (i.e., MultiBeast)

If FakeSMC.kext is in S/L/E or L/E..., it will be in kextcache and should not be in EFI/CLOVER/kexts/...
InjectKexts/Yes tells Clover to inject EFI/CLOVER/kexts/...
InjectKexts/Detect tells Clover to inject EFI/CLOVER/kexts/...

S/L/E/FakeSMC.kext or L/E/FakeSMC.kext are valid configurations

InjectKexts/Yes is addresses either FakeSMC.kext installation

When I now run the "audio_cloverALC-130_v0.4.command" script, the hard coded "injectKexts Yes" of that script overrides my "InjectKexts Detect", to "Yes". During the reboot, after the script completed its routines, all kexts will now be loaded from /Clover/Kexts/other and the duplicates in kernelcache will be ignored. For Skylakein combination with High Sierra an undesirable situation.

There is no special kextcache consideration regarding Skylake/High Sierra

I reset the "InjectKexts" parameter from the scripts's "Yes" to "Detect" , and with Kextbeast copy the newly generated realtekALC.kext to /L/E then run "sudo kextcache -i /" to get the cache updated after the copy operation.

realtekALC.kext is not an executable and no reason to include in it kextcache.
Not clear what the real problem is; this procedure is not necessary.

Not familiar with lockup/reboot/sleep problems you are reporting. Please reply with @RehabMan links to the problem and recommendations.

Kextcache is a disc file used for boot only; unlikely to cause random reboot or sleep problems because it is long gone when the Desktop appears. Kextcache problems always result in boot failure.

There is no reason to move realtekALC.kext. There is no reason to run cloverALC more than once. If you have decided that InjectKexts/Detect is the only solution that works, stick with it.

The issues appear to be understanding and correctly using kextcache and Clover.

 

[Henties]

Hi @toleda Thanks for your very detailed explanation with which I can live with. Presently I have no kexts in /Clover/Kexts/other, all kexts are placed in /L/E and the system seems fine.
My confusion and or misunderstanding stems from the fact that I took what I gleaned from the Clover WiKi to be correct, instead that led me down the garden path indeed, good and solid. Nevertheless my system is working well the way it is configured presently, therefore thank you once again for your patience and extended explanations
Keep well and greetings Henties

 

[puriaa]

hello
i need unpatched appleHDA.kext for 10.13.4
please someone send that for me

tnq

 

[Mario1964]

Hello , after the upate to 10.13.4 the hdmi audio disappear , how can i solve ?

 

[toleda]

after the upate to 10.13.4 the hdmi audio disappear

See AppleHDA HDMI Audio/Post #2

 

[Mario1964]

See AppleHDA HDMI Audio/Post #2

Thx

This is the file from 10.13.3 , after installed with kexthelper use your audioclover_hdmi and all work again