Contribute
Register

AppleHDA Realtek Audio [Guide]

don't know why "sudo touch /System/Library/Extensions && sudo kextcache -u /"
didn't work, but Kext utility worked.
Conclusion is not correct, because
restore my clone
Kext Utility was not necessary; clone solved problem, expected.
 
@toleda,
I have the exact same issues as @zedoc.

After running your script for my audio, I get stuck at boot.

I'm also running the Z97MX-gaming 5 (so I have alc1150) with the latest version of Clover.

Slightly off-topic, but I went from 10.13 (i.e. first rev of 10.13) to 10.13.3 because I hadn't been able to get the update to work like normal.

Finally got that part working today, and I went to run your script like I always do, and here's where I get confused.

1) In the past, after every macOS update I ran your script. You mentioned to @WandererRev that from 10.13.2 to 10.13.3 there was no audio update in macOS.
For 10.13.2 Update, no boot; all other effected updates, no audio
I was different because I went from 10.13 to 10.13.3, but if this is the case–that is it bad to run your script when nothing is changed in macOS–why? If it is bad, maybe you should add that to the notes for this thread.

2) I didn't have the problem until I used your script, so I assume it's related to that. You also said:
Audio does not work because of kext cache problem.
System won't boot because of kext cache problem.
In my case, I ran your script and then my computer stopped working (not blaming you or the script, just want to figure this out). Is it possible that under certain conditions, the script could cause kext cache issues?

3) I got stuck first at the same part as @WandererRev:

Code:
Ethernet [AtherosE2200]: Link up on en0, 1-Gigabit, full-duplex, no flow-control
en0: starting optimistic DAD immediately for xxxx:x::xxxx:xxxx:xxxx:xxxx
en0: DAD complete for xxxx:x::xxxx:xxxx:xxxx:xxxx - no duplicates found.
utun_ctl_connect: creating interface utun0 (id utunid0)

After that, I waited about ten minutes and I got to this, duplicated six times:
Code:
IOConsoleUsers: time(0) 0->0, lin 0, elk 1,
IOConsoleUsers: gIOScreenLockState 3, hs 0, bs 0, now 0, sm 0x0

As I type this, that's where it's still stuck, so I don't think it will be moving. I'm sure those lines don't refer directly to audio issues, but you might know more about the order of events in the boot sequence, so it may help to pinpoint the issue(s).

4) What is the best option(s) moving forward? Is it always a good idea to rebuild the kext cache after every update? After your script as well? Is this still the best command for rebuilding it:
Code:
sudo touch /System/Library/Extensions && sudo kextcache -u /

I apologize for the long thread, but I want to get this fixed, as well as leave this for someone else with the same issues. Thanks for your continued support for the tonmacx86 community!

TL;DR: have alc1150 - updated from 10.13 to 10.13.3 - ran script - boot hangs - never happened with past updates since 10.10.x - what do
 
@toleda
Just as an update, I might have figured out part of the issue. Some of it may be off-topic, so if I need to move this somewhere else that's fine.

I was able to get the computer to boot by going in to single-user mode and running:
Code:
sudo touch /System/Library/Extensions && sudo kextcache -u /
After that I rebooted as normal.

When I got into the desktop, it looked as if I hadn't installed the NVIDIA Web Drivers. I tried to think of everything I did in my last post, but one thing I forgot to mention is that when I first ran the script, my computer had SIP fully enabled (0x00). The script told me to set (0x3) mode so I did. It turns out, at least with me, the NVIDIA drivers get borked in that mode.

Now, I have SIP set to (0x67). I'm not sure if that's an isolated issue with my system, or if other people have the same issues.

I ran the script again, and it caused it to hang. I once again went into single-user mode to rebuild the kext cache. I rebooted and it was fine. However, I still cannot get the audio to work now.

One thing I noticed is that the script put my audio kext under the 10.13 directory, not Other. Is this normal? I have all my other kexts in Other, so that's the only one sitting in 10.13. I tried moving it and rebuilding the kext cache, but that didn't help either.

I'm gonna leave the audio alone for now because I have work, but I'd appreciate any suggestions at this point.

Thanks!
 
@toleda
Just as an update, I might have figured out part of the issue. Some of it may be off-topic, so if I need to move this somewhere else that's fine.

I was able to get the computer to boot by going in to single-user mode and running:
Code:
sudo touch /System/Library/Extensions && sudo kextcache -u /
After that I rebooted as normal.

When I got into the desktop, it looked as if I hadn't installed the NVIDIA Web Drivers. I tried to think of everything I did in my last post, but one thing I forgot to mention is that when I first ran the script, my computer had SIP fully enabled (0x00). The script told me to set (0x3) mode so I did. It turns out, at least with me, the NVIDIA drivers get borked in that mode.

Now, I have SIP set to (0x67). I'm not sure if that's an isolated issue with my system, or if other people have the same issues.

I ran the script again, and it caused it to hang. I once again went into single-user mode to rebuild the kext cache. I rebooted and it was fine. However, I still cannot get the audio to work now.

One thing I noticed is that the script put my audio kext under the 10.13 directory, not Other. Is this normal? I have all my other kexts in Other, so that's the only one sitting in 10.13. I tried moving it and rebuilding the kext cache, but that didn't help either.

I'm gonna leave the audio alone for now because I have work, but I'd appreciate any suggestions at this point.

Thanks!


Have you got lilu.kext? Try delete lilu.kext
 
gonna leave the audio alone for now
Your boot fail fix is correct for either Single User Mode or Recovery Mode
Unfortunately, your procedure is not correct which is why the problem reappears.
The kext cache problem occurs when you boot Install macOS ...; the result is incorrect kext cache.
When the Desktop arrives and you run cloverALC, the kext cache is rebuilt again but incorrectly.
Restart to boot failure.
Instead, when the Desktop arrives, restart.
The Install macOS ... partition is gone
Back to normal, Boot macOS ..., when the Desktop arrives, run cloverALC if no audio.

After a fresh install, restart and then run cloverALC (MultiBeast Audio Failure [Solved])
After a Software Update, restart and then run cloverALC
The clue is "Install macOS ..."; restart is required before installing audio
 
hey Toleda,thanks so much for his guide!and also thanks to JB007 for pointing this thread..
 
Toleda.......thanks for all the hard work that you have put in on creating this thread.

I apologize but after having read through your guide multiple times I'm still a little confused regarding the process to enable audio with my ASRock H170m-itx board.

I ran MultiBeast post the initial install of High Sierra and specified ALC892 audio (audio ID 1) together with the 100/200 series audio fix however I have no audio.

Its not clear to me which steps I have missed so I'm hoping that you might give me a little feedback regarding the following:

Point 1 of Section II.3 of guide (MultiBeast) states "Tool - same technique as CloverALC. Does this indicate that I need to download and run the audio_cloverALC.command file before running MultiBeast? If it is required can run it now or di I need to revert back to standard AppleHDA, run it and then run MB?

Section IX.1 of guide - Select one option. Do I require to do this given that I have a 100 series board? If so I can simply download and install the files in ssd_hdef-1-100-hdas.zip? Also I am assuming that steps IX.1.3 and IX.1.4 are not required since I have a 100 series board.

Thanks for your guidance, it is much appreciated.
 
ran MultiBeast post the initial install of High Sierra and specified ALC892 audio (audio ID 1) together with the 100/200 series audio fix however I have no audio.
Those are the correct choices. Something else is wrong, see Post #1/IV. Problem Reporting
If it is required can run it now or do I need to revert back to standard AppleHDA, run it and then run MB?
No, either, not both. The point is both methods produce the same result.
I am assuming that steps IX.1.3 and IX.1.4 are not required since I have a 100 series board.
Correct.
 
Those are the correct choices. Something else is wrong, see Post #1/IV. Problem Reporting

No, either, not both. The point is both methods produce the same result.

Correct.
It turns out that the fix was as simple as going to Sound in the control panel and turning up the output volume (slider at the bottom of the dialog box).

So just to clarify, the following are the steps that I took:
  • Installed High Sierra as described in the guide.
  • Ran Multibeast specifying ALC892, Audio ID1 and 100/200/300 fix
These appear to be the only requirements to have audio with an iMac 14,2 system despite the various steps from the guide that I omitted to complete.
 
v1.1: 2/28/18 - cloverALC supports 300/200/X299/X99 audio controller and macOS bundle-id, IX. Unsupported/Non-working AppleHDA Realtek Audio supports 300/200/X299/X99 audio controller and dsdt/audio device rename.

See Post #1
 
Back
Top