Mavericks Realtek ALC AppleHDA Audio

[Haravikk]

Many thanks for providing all of this!

 

The description mentions that the patching "provides pin configuration", is this the same thing as "Jack retasking" as mentioned on many recent Asus motherboards? If so, I was just hoping to confirm whether this can be used to repurpose front-panel audio connectors to provide additional speaker outputs? The motherboard I'd like to use only has two but I need three, but I can add an additional two front panel ports, can I combine these for 5.1 sound? If so, is there a guide somewhere on how to do this? I didn't see anything, but could easily have missed it…

[toleda]

the AppleHDAController (temporary) patch in Clover caused a KP. 

No surprise.  The AppleHDAController (temporary) patch is for 9 Series motherboards only; does not apply to your 7 Series motherboard.

The description mentions that the patching "provides pin configuration", is this the same thing as "Jack retasking" 

No.  Retasking requires modifying the pin config and pathmap.  Audio ID: 2 (see Post #1) supports retasking motherboards with 3 audio posts (green/speakers out, blue/line in, pink/mic in) to 5.1 analog (green/front, blue/rear and pink/center and sub).  AppleHDA does not support any retasking functions programatically. More information, see Post #1, M-Realtek_ALC_AppleHDA_Customization.pdf

[toleda]

ALC885 patch for 10.9.4. needs badly, 

 

v1.7 - 7/14/2014 - Mavericks 10.9.4 AppleHDA Support Available

[Haravikk]

No.  Retasking requires modifying the pin config and pathmap.  Audio ID: 2 (see Post #1) supports retasking motherboards with 3 audio posts (green/speakers out, blue/line in, pink/mic in) to 5.1 analog (green/front, blue/rear and pink/center and sub).  AppleHDA does not support any retasking functions programatically. More information, see Post #1, M-Realtek_ALC_AppleHDA_Customization.pdf

 

Thanks for clarifying! From what I've heard the pin-mapping under Windows are simply stored under a registry key, and can be manipulated manually if the GUI for re-assigning them doesn't work (some motherboards seem to have had that problem), with that in mind I'm wondering, would it be easier to configure the new mapping under Windows then somehow transfer the settings over to OS X? Has anyone does this? Are the mappings the same?

[mr. west]

Can someone post the original AppleHDA for 10.9.4.  Need the vanilla file, don't want to reinstall

[MacUser2525]

Can someone post the original AppleHDA for 10.9.4.  Need the vanilla file, don't want to reinstall

Download the Combo update from Apple support then use Pacifist to extract the .kext from it.

[toleda]

I'm wondering, would it be easier to configure the new mapping under Windows then somehow transfer the settings over to OS X? Has anyone does this? Are the mappings the same?

Windows pinconfigs do not work with AppleHDA.kext, result no audio.

Download the Combo update from Apple support then use Pacifist to extract the .kext from it.

No Mavericks Combo Update has the complete AppleHDA.kext.  Extracting from the installer does not work. Only method that results is the complete native Mavericks AppleHDA.kext is a fresh install.

[arsradu]

Thank you so much for the tutorial.

It's a good tutorial but I've still got a lot of questions. There are so many ways of doing this. I don't even know which one is better. It probably depends on many things so there isn't probably a "best for all cases" solution.

And I've got a few questions in order to understand what the hell is going on with these patched AppleHDA kexts. How do they work? Why don't they work for me? What does the HDAEnabler do? Do I need it? Do I need an Enabler? When do I need an enabler? In which cases? Can it remain the same after AppleHDA kext update? Do I need to update that (the Enabler), as well? It's really, really, really, really frustrating not to be able to boot into your system and not know what exactly caused it and how to fix it.
I reinstalled both Mavericks and Yosemite at least 10 times each during last month. And I had to wipe my HDD clean at least 3 times in the last 2 months. It's too much. And I'm tired. I just want to enjoy these OSes. But for that I need sound! And, in case something bad happens, I need to understand why did it happen in order to be able to fix it.

So, please, have a bit of patience and explain to me what to do to get sound working for the following scenario:
1. Clover as bootloader
2. Mavericks and Yosemite installed on the same drive (so I'll be using the same Clover config.plist for both OSes). I will most likely need a different patched AppleHDA kext for Yosemite as well (or maybe not?).
3. ALC892
Usually when I install the patched AppleHDA (I tried some other ones, not made by toleda, but that's not relevant for this case anyway), I usually do it like this (if you have better ways of doing this or if you would recommend one way over the other, please, tell me):

1. Command line

sudo -s[password]cp -r -v /path-to-the-patched-kext-folder/AppleHDA.kext /System/Library/Extensions/

Then I delete the kernel cache with this command, so that it can be recreated automatically on the next reboot (assuming I can boot again in normal mode...):

rm -r -v /System/Library/Caches/com.apple.kext.caches/Startup/*

2. Kext Wizard app

I install the kext, then I rebuild caches and repair permissions (also from Kext Wizard).

Now, I've always wondered about this: which method is better? Cause I've tried both and I've never been able to tell which one is better...if there is one better than the other.

Also, about the layout ID... Maaan, this has brought a LOT of frustration. Why Layout ID 1? I mean, why not 16 or 532 or whatever number you might think of? Is this set somewhere in the kext itself? If so, where? How can I tell which Layout ID should I be using/injecting in Clover for a specific AppleHDA kext, assuming I don't already know that kext.

I'm asking cause this is another one of my biggest frustrations with this AppleHDA kext. If you don't match the kext to the injected layout id, you won't be able to boot anymore. If, on the other hand, you injected a layout ID, but you don't have a patched AppleHDA kext (for example you've got the vanilla AppleHDA kext instead), you won't be able to boot anymore. If you selected No injection in Clover, for audio, but you've got a patched AppleHDA kext, you won't be able to boot anymore. If you've selected Detect, in Clover, but something else is wrong, you won't be able to boot anymore. And this is annoying as hell!

Also, I'm not sure I understood correctly, but for the Clover patching method, I need to always have those files in the Downloads folder, even after I successfully (hopefully) patched the vanilla kext and I got everything up and running? Why? How does that affect it?

So, I think I wrote enough. What would you guys recommend for my scenario?

As a general note, I would like a method/solution that is persistent (I don't have to reinstall after each software update) and something that can be used for both Mavericks and Yosemite, since, as I said above, I'm gonna dual boot, which means that I'm gonna be using the same Clover config.plist to boot both OSes.

Can anyone help?

PS: hardware info can be found in my signature. If you need more info, please, let me know.

[Ingwar77]

... Only method that results is the complete native Mavericks AppleHDA.kext is a fresh install.

 

Not for me    Patch doesn't work

 

Prepare Desktop/audio_ALC885 ...

/......./audio_ALC885/audio_alc885-94_patch.command: line 33: cd: 885885: No such file or directory

Install files ...

Password:

rm: /System/Library/Extensions/AppleHDA.kext/Contents/Plugins/AppleHDAHardwareConfigDriver.kext/Contents/Info.plist: No such file or directory

install: Info-94.plist: No such file or directory

rm: /System/Library/Extensions/AppleHDA.kext/Contents/Resources/*.zlib: No such file or directory

install: Platforms.xml.zlib: No such file or directory

Patch binary/Optional - Default: No Patch

Fix permissions ...

Kernel cache...

Finished, restart required.

logout

 

After reboot nothing, just silence

[toleda]

/......./audio_ALC885/audio_alc885-94_patch.command: line 33: cd: 885885: No such file or directory

Patch failed.  Script problem, repo updated.

Fix:

1. Delete Desktop/audio_ALC885 and Downloads/audio_ALC885-master

2. toleda/audio_ALC885/Download ZIP

3. Double click Downloads/audio_ALC885-master/audio_alc885-94_patch.command

[toleda]

What would you guys recommend for my scenario?

Working non native OS X audio requirements: patched AppleHDA.kext and Audio ID injection, see Post #1.

1. Patched AppleHDA: assigns motherboard audio codec to a kext support codec and provides specific layout (audio devices), pathmap (codec nodes) and pinconfig (motherboard audio connectors) definitions

2. Audio ID injection: kext, dsdt, ssdt or bootloader injection of layout-id required for OS X to load the correct tables for working audio.

 

Only one technique should be implemented. HDAEnabler is a kext layout-id injection technique, not recommended in Clover or Chameleon installations.

 

Clover Recommendation: B85-HD3/892 (use Audio ID: 1)

1. Clover Injection -  toleda/audio_CloverALC  (EFI: edit config.plist and install realtekALC.kext)

2. Mavericks/native AppleHDA.kext - audio_ALC892/cloverALC/audio_cloverALC892-90_patch.command

3. Yosemite/native AppleHDA.kext - audio_ALC892/cloverALC/audio_cloverALC892-90_patch.command

 

Yes, run the same script on each install.  Result working 892 audio for Mavericks and Yosemite.

 

The script rebuilds kernel cache.  No other action is required.  The cloverALC technique is persistent.

One caution, any other patched AppleHDA.kext/injection technique must be removed; a clean install is the best starting point.

 

Other Answers:

Layout-id has to be native to AppleHDA.kext

Layout-id must be specified by the developer

AppleHDA.kext (native or patched) does not have any negative effect on boot success.  The outcome is no audio, not failed boot

No injection/Wrong Audio ID outcome is no audio

Current scripts cannot be moved: the idea, simply double click and done. 

[aikidoka25]

I think there is a bug on the script, at least on the version I downloaded yesterday from github. It tried to change to directory 885885, a typo error.

[toleda]

I think there is a bug on the script

You are correct.  Fixed.  Thanks.

[arsradu]

Working non native OS X audio requirements: patched AppleHDA.kext and Audio ID injection, see Post #1.

1. Patched AppleHDA: assigns motherboard audio codec to a kext support codec and provides specific layout (audio devices), pathmap (codec nodes) and pinconfig (motherboard audio connectors) definitions

2. Audio ID injection: kext, dsdt, ssdt or bootloader injection of layout-id required for OS X to load the correct tables for working audio.

 

Only one technique should be implemented. HDAEnabler is a kext layout-id injection technique, not recommended in Clover or Chameleon installations.

 

Clover Recommendation: B85-HD3/892 (use Audio ID: 1)

1. Clover Injection -  toleda/audio_CloverALC  (EFI: edit config.plist and install realtekALC.kext)

2. Mavericks/native AppleHDA.kext - audio_ALC892/cloverALC/audio_cloverALC892-90_patch.command

3. Yosemite/native AppleHDA.kext - audio_ALC892/cloverALC/audio_cloverALC892-90_patch.command

 

Yes, run the same script on each install.  Result working 892 audio for Mavericks and Yosemite.

 

The script rebuilds kernel cache.  No other action is required.  The cloverALC technique is persistent.

One caution, any other patched AppleHDA.kext/injection technique must be removed; a clean install is the best starting point.

 

Other Answers:

Layout-id has to be native to AppleHDA.kext

Layout-id must be specified by the developer

AppleHDA.kext (native or patched) does not have any negative effect on boot success.  The outcome is no audio, not failed boot

No injection/Wrong Audio ID outcome is no audio

Current scripts cannot be moved: the idea, simply double click and done. 

Thank you very much, toleda.

 

So what the script does is unpacking the content of the 892 zip file, then taking its content and replacing the existing one inside the AppleHDA.kext itself. After that, performs a cleanup, sets up permissions on the AppleHDA.kext and rebuilds cache.

And the reason why the script cannot be moved is that the path to the 892.zip is in Downloads/audio_ALC892-master. Ok, I got it. But once everything is done, removing the files from my Downloads folder should not affect the sound functionality in any way, right? Since AppleHDA.kext is patched, Clover has been injected with (for my case) layout-id 1, the realtekALC.kext has been set in Clover/kexts/10.9 or 10.10 (for Yosemite).

And the script must be run for each of the two OSes since the AppleHDA.kext is different. Of course, now it makes perfect sense. It's the same script, the same patch, just different kext to patch.

 

Now speaking about Clover, there is a part that I didn't quite understand:

 

# 2. Verify Clover/config.plist/KernelAndKextPatches/KextsToPatch/AppleHDA/ALC892

# 3. Verify Clover/config.plist/HernelAndKextPatches/KextsToPatch/AppleHDA/xml>zml

 

What do you mean by that?

Also, I think there might be a little typo in your step 3...  But since that line is not executed, it doesn't affect anyone. 

 

So, question is: how do I do this? I was trying to use Clover Configurator, but I couldn't figure out how to add those things... I've already gotten something for AHCI... I attached a screenshot of what I got right now. I can't figure out what exactly do you mean by those two steps. Little help here?

 

Also, please, tell me how to make that patch.command file executable so that it can run on double click. I couldn't just download the file from the github.  It always opens in a new browser tab instead of downloading. I suppose that if I were able to download the file, it would have been already executable and I would have been able to run it. But..apparently the way I got it didn't make or keep it executable.

[toleda]

So what the script does is unpacking the content of the 892 zip file, then taking its content and replacing the existing one inside the AppleHDA.kext itself. 

 

What do you mean by that?

 

Also, I think there might be a little typo in your step 3.. 

 

Also, please, tell me how to make that patch.command file executable so that it can run on double click. I couldn't just download the file from the github.  

The script does not remove anything, it adds 892 files.  All native files remain and can be updated without effecting the 892 files.

 

The kext patches are included in audio_CloverALC/config-audio_cloverALC.plist.  Open a Clover Configurator window and copy the noted patches from config-audio_cloverALC.plist and paste to another Clover Configurator window with your EFI/Clover/config.plist.

 

Note the typo.

 

Github downloads:

1. download the repo: select "Download ZIP", right side of Github window, last button. Double click on the desired .command file.

2. download a file: select "View Raw"

[arsradu]

The script does not remove anything, it adds 892 files.  All native files remain and can be updated without effecting the 892 files.

 

The kext patches are included in audio_CloverALC/config-audio_cloverALC.plist.  Open a Clover Configurator window and copy the noted patches from config-audio_cloverALC.plist and paste to another Clover Configurator window with your EFI/Clover/config.plist.

 

Note the typo.

 

Github downloads:

1. download the repo: select "Download ZIP", right side of Github window, last button. Double click on the desired .command file.

2. download a file: select "View Raw"

 

Thank you, toleda. I'll give it a try.

 

Also, I already tried the Raw button (in case that's what you were referring to). And it still opens the file in a new tab, in browser, instead of downloading the file on my computer. Anyway, I'll download the whole repo, as a zip and take what I need from there.

 

Edit: 

What does the realtekALC.kext (the one in the Clover/kexts/10.9 folder) do? I mean...the AppleHDA.kext is patched, the layoutID is injected in Clover's config.plist. What does this realtekALC.kext do?

 

Edit2:

I couldn't get it to work, man. I don't know if I did something wrong or didn't do something that I should have done. But I got no sound with either Mavericks or Yosemite.

 

So I attached the Clover config.plist, my ioreg, and the installed (patched) kext for debugging purposes. You already know which OSes I would like to have sound on, so no need to specify that. And you already know which patching method did I use. But please, let me know if you need anything else.

 

Thank you.

 

Archive.zip

[toleda]

What does this realtekALC.kext do?

don't know if I did something wrong

realtekALC specifies pinconfigs for a codec/layout.

Clover Configurator: do not select Info.plist Patch for the AppleHDA patches, the patches are for the binary.

Edit config.plist and reply with new config.plist and IOReg.

[arsradu]

realtekALC specifies pinconfigs for a codec/layout.

Clover Configurator: do not select Info.plist Patch for the AppleHDA patches, the patches are for the binary.

Edit config.plist and reply with new config.plist and IOReg.

Ok, I unchecked those, saved the changes, repaired permissions (I don't know why I did that, there was nothing to repair) and restarted. Problem is....I can't boot into the OS anymore. I booted from the USB stick in order to be able to take the ioreg and the config.plist.

So I'm not sure what triggered that, and I know you said the worst case scenario is no sound, not boot failure, but this is exactly what I'm getting now, and I've got no idea why. It hangs during booting.

I booted in verbose mode and the last line was about Bluetooth..something. And it stays like that forever.

The files you requested are in the attached archive.

Archive.zip

[toleda]

I booted in verbose mode and the last line was about Bluetooth..something. And it stays like that forever.

The files you requested are in the attached archive.

Audio loads before the Bluetooth message; graphics broke.  Attached config.plist is completely different from the previous attachment; setting every ACPI/DSDT/Fixes to YES likely is the problem.

[arsradu]

Audio loads before the Bluetooth message; graphics broke.  Attached config.plist is completely different from the previous attachment; setting every ACPI/DSDT/Fixes to YES likely is the problem.

Those are the defaults. I haven't touched those.

The USB stick has exactly the same ACPI fixes. The default ones. And I can boot with it no problem.

[fusion71au]

@arsradu,

 

Can you boot the hard drive in safe mode?  Are you talking about Mavericks or Yosemite?

 

Maybe try adding kext-dev-mode=1 to the boot section of the config.plist in order to load the patched AppleHDA.kext for Yosemite....

<key>Arguments</key>
<string>kext-dev-mode=1</string>

..then rebuild caches...

sudo kextcache -prelinked-kernel

Good luck!

 

Edit  I just noticed in your latest config.plist, you've changed InjectKexts from "Detect" to "Yes".  Could you change back to "Detect" and see if that restores your boot?  Maybe there is a conflict if Clover is injecting a kext (FakeSMC.kext) that is already in S/L/E?

[arsradu]

@arsradu,

 

Can you boot the hard drive in safe mode?  Are you talking about Mavericks or Yosemite?

 

Maybe try adding kext-dev-mode=1 to the boot section of the config.plist in order to load the patched AppleHDA.kext for Yosemite....

<key>Arguments</key>
<string>kext-dev-mode=1</string>

..then rebuild caches...

sudo kextcache -prelinked-kernel

Good luck!

Hey,man.

 

Well, I was talking particularly about Mavericks right there. But, right now, I can't boot into either one of them from the HDD.

 

Mavericks

              in Safe Mode = it does boot

Yosemite

              1. in Safe Mode (with no "kext-dev-mode=1" boot flag) = it doesn't boot (hangs at AppleMobileDevice is in the exception list, allowing to load*).

              *I always thought that was funny, in a way. It says "allowing to load". But it's not freaking loading!

              2. in normal mode, with boot flag "kext-dev-mode=1" = it doesn't boot (same as #1)

              3. in Safe Mode, with boot flag "kext-dev-mode=1" = it doesn't boot (same as #1)

              4. from the USB stick (in normal mode) = it does boot.*

              *But, for this case, the FakeSMC kext is in the newly created 10.10 folder in Clover/kexts and there is no other kext in either one of the other folders. Also, it's loading the vanilla OS X Yosemite, with all the default kexts, no custom kext in there (except for the FakeSMC, of course). Also, that means there is not something related to the kexts themselves, but something with the Clover's config.plist, probably.

 

Last time I had this issue, it was because of the FakeSMC, if I'm not mistaken. BUT, the FakeSMC is present in Clover/kexts/Other. The one for Mavericks is also present in the 10.9 folder. Right now, I've got two kexts in those folders: FakeSMC.kext and realtekALC.kext. And they are in both the 10.9 folder and the Other folder.

I tried once to also create a 10.10 folder and put my kexts in there, as well as in the 10.9 folder, and I couldn't boot neither Yosemite, nor Mavericks anymore... Not sure it was because of that or maybe other issues though... So that's why I put the kexts for Mavericks in the 10.9 folder, and the ones for Yosemite, in the Other folder. But right now that doesn't seem to work either. So..I don't know what to do to be able to successfully dual-boot both OSes.

 

I don't know if I wanna try rebuilding the cache using that command for the following reasons:

              1. last time I tried that (and I tried it 2 times before), after doing that, I wasn't able to boot at all (I was getting an error saying Boot Failed, rebooting in 10 seconds...and then reboot, and that no matter if I was booting in normal or safe or single user or any other mode). So...I'm not sure I wanna do that.

              2. the kernelcache seems to be automatically rebuilt when you boot in safe mode. I was following the text on my screen when booting in safe mode and, at some point it said "rebuilding cache...bla bla bla". So I'm not sure that's necessary when booting in safe mode. Also, as I said, I don't think my Yosemite booting problem is related to the kext cache. But probably to the FakeSMC kext. But, assuming it might be because of its placement, I was planning on dealing with that once i figure out the problem with Mavericks, for which the FakeSMC kext is in the right place (and also I'm getting a different behavior for that one).

 

 

 

[arsradu]

Edit  I just noticed in your latest config.plist, you've changed InjectKexts from "Detect" to "Yes".  Could you change back to "Detect" and see if that restores your boot?  Maybe there is a conflict if Clover is injecting a kext (FakeSMC.kext) that is already in S/L/E?

Before, it was set to Detect. And, if I remember correctly, I still had that problem.  Can't really try again now since I'm at work.

But...FakeSMC is not in S/L/E/. It's only in Clover/kexts/10.9 or Other or 10.10... So I'm not sure that's the problem.

 

Yes, I set that to Yes (originally it was set to Detect), because that was in the instruction that toleda posted for patching the audio. And in an attempt to find out why doesn't the sound work, I tried to switch that to Yes, as you saw.

[Ingwar77]

... repo updated. ...

Thanks a lot

[toleda]

 

Mavericks

              in Safe Mode = it does boot

Suggest focus on Mavericks.  Your config.plist is not default; try a native config.plist with with only the few essential settings.  No need to duplicate kexts; use the 10.9 folder (other is empty).  Screenshot above shows 10.10 and does not show any boot messages.  Clover/Safe Mode and Without Cache is not working in 10.10.  If you used either selection, only fix is to boot single user mode to rebuild permissions.