WORK IN PROGRESS – Last update: 6 September 2009 - 23:55 (currently working on changes for Snow Leopard)

Introduction
I started to write this tutorial, not as tutorial, but as "steps to reproduce" for something I ran into, shortly after I wrote: "Pinconfig for Linux users" (here). It was something that I myself could not explain/pinpoint... and nobody was either able or willing to solve this mystery for me. That's when I started to make notes, but it was months later (June 17th) when I decided to make something useful out of it – in the hope that my info will be helpful somehow. And I started to make changes for Snow Leopard on 2 September 2009 – after a successful installation, without any modification whatsoever to /dsdt.aml or the to legacy audio kext files!

Please note that my guides/tutorials are: "Educational Information Only" and thus not a real solution i.e. you can use my info when you want, to learn something new. However, I am not going to solve audio problem(s) for Hackintosh users – just a legal restriction, not to mention that I don't have the time for it.

Also: The information in this tutorial is not something I have "discovered" but it can be found on this forum, and was posted by other forum members long before me i.e. I am not taking credit for it, but for my writing.

Now. I have a simple ASUS P5K PRO motherboard in my Hackintosh (for editorial work only) and the on board ALC883 worked since day one, but I still used HDAEnabler.kext with a modified copy of AppleHDA.kext from some previous OS X version. Time to change things. The first things I did was to make a "Cheat Sheet for Pin Default" (which will be available soon) because I kept looking up this info (I'm not perfect no) so now I got all info at hand. Which I tell you helps a lot when you want to fix audio problems.

And no, this info isn't necessarily limited to ALC883, but that's what I use, and thus you'll find references to it throughout this tutorial. Also, there are obvious other ways to get audio going, which might be even easier, but dragging a kext into Kexthelper (for example) won't help people learn anything. Not that this mini-tutorial is perfect, but it should help.

Anyway. I first installed a brand new 1TB hard drive, as third drive (F8 enables me to select the hard drive to boot from) and installed my retail OS X 10.5.6 on it (including the upgrade to 10.5.7). Everything was vanilla, well almost, but I did not install injectors like HDAEnabler. And yet I got audio going after using a simple DSDT hack (see below, but make sure to read everything). Let's start with some screen shots:

Screenshots – update me!
System Preferences / Sound:
http://i639.photobucket.com/albums/uu118/T...und-outputs.png
http://i639.photobucket.com/albums/uu118/T...ound-inputs.png

Audio MIDI Setup:
http://i639.photobucket.com/albums/uu118/T...midi-output.png
http://i639.photobucket.com/albums/uu118/T.../midi-input.png

IORegistryExplorer:
http://i639.photobucket.com/albums/uu118/T.../ioref-hdef.png
http://i639.photobucket.com/albums/uu118/T...AController.png
http://i639.photobucket.com/albums/uu118/T...leHDADriver.png

tmongkol reminded me about the microphone error, one that I also made in my other tutorial, which I apparently never fixed and thus it ended up here again. Oops. Thank you tmongkol! Please note that I won't update the screen shots before I'm done (saving me some time again).

DSDT hacking – introduction
I'm sure that DSDT hacking sounds scary, but it isn't. Let's start by explaining DSDT a little first, which is short for Differentiated System Description Table and it is part of ACPI. But before we continue, install DSDT Patcher which includes the necessary Intel ASL compiler/decompiler for the following procedures.

Getting The Data
To get your DSDT table on OS X you have to open a terminal window and enter:

This will write the ACPI tables to ioregdump.txt on your desktop, which includes the DSDT table. Now remove all other tables but DSDT. Then copy the hex values to a HEX Editor like HexEdit or 0xED and save it as dsdt.dat

DSDT De-Compiling
Now we need to de-compile the newly obtained file with:


DSDT Patching
Let's cd into the directory where I have DSDTPatcher installed (change path accordantly) and open dsdt.dsl with nano:

Here are the most commonly used keyboard shortcuts for Nano – used in this tutorial:

CTRL + X (exit)
CTRL + O (save)
CTRL + W (search)
CTRL + Y (page up)
CTRL + V (page down)
CTRL + K (cut line)

The next thing I did was to copy the following HDEF snippet (my first edition) into my dsdt.dsl with (press CTRL + W and enter "Device (USB0)" to search for the right spot, and paste the new HDEF section below the closing curly bracket (}) of Device (USB0). Just above Device (USB0). Now press CTRL + O to save your changes.


Testing however revealed that I didn't need codec-id nor device-type and thus I removed both of them them, including the Buffer() {} parts, and reduced the Package length accordantly to 0x06.

Note: You can also change the buffer length and use either Buffer (0x00) or Buffer (Zero) under PinConfigurations when you remove the single value (0x00) from between the curly brackets.

We also need Method DTGP which I've put below Method (_PTS, 1, NotSerialized) and above Method (_WAK, 1, NotSerialized)

Ok. Time to re-compile dsdt.dsl:

Giving you something like: "Compilation complete. 0 Errors, 6 Warnings, 0 Remarks, 46 Optimizations"

There should not be any errors! And if you do happen to get errors... then fix them first with help of search (Google) since that is really out of scope for this tutorial. Let's just assume that everything is cool, and thus is it time to copy dsdt.aml to / and to reboot:


ChameleonSM
Nothing happened the first time I did. I mean having dsdt.aml in the right place (/) is one thing, but you'll also need a boot loader which is capable of injecting it at boot time. I was still using "the old" Chameleon and thus here's what I did – after downloading chameleon.zip and unpacking it:

Any other clone capable of injecting your modified (patched) dsdt.aml is fine by me – as long as it works.

Note: The boot file of ChameleonSM cannot be used in conjunction with Snow Leopard - system won't boot with it – and the cure for this is to use an older /boot file (search this forum for it, in one of the many Snow Leopard installation guides).

After The First Reboot
The first thing most people do is to check System Profiler and so did I. No change – still showing my input and output jacks. The next thing I did was to open System Preferences – Sound and that was also still showing the same info. Weird. I started to wonder if I forgot to clear Extensions.mkext so I fired up a little script:

For Leopard 10.5.x installations

For Snow Leopard 10.6.x installations

But after the reboot everything appeared to be unchanged and thus I checked the output jacks, to find only the black output jack to be functional. Ok, so something changed, since all but my gray output jack worked before I started. Not really what I expected, but the change worked.

Note: What I missed (after re-reading this particular part of the text) is that I injected PinConfigurations from dsdt.dsl and thus it isn't strange that System Profiler showed the same in- and output jacks. I just mixed the order of events during my cleanups (I moved some text) of this tutorial.

I fired up IORegistryExplorer (part of xcode) to see what, if anything, had changed, and noticed a new reference to HDEF. Hm, so that's what this dsdt thing it does. It adds "properties" like layout-id and what not to HDEF. Nothing new here for experienced hackers, but it is probably a revelation for noobs. You know, all this new stuff. But whatever.

I was on the right track, but I was intrigued by the fact that both System Profiler and System Preferences – Sound showed info that I wasn't expecting. Especially since layout 883 was nowhere to be found in AppleHDAController.kext nor AppleHDAPlatformDriver.kext Time to start digging. Time to remove stuff.

Looking For Answers – you can skip this part
I only removed the data in the steps below temporarily, just to make sure that it wasn't getting any info from it, and yes I re-installed the original files from 10.5.7 after I was done testing.

1) I removed the following sections from AppleHDAController.kext:
CodecAddressFilterArray, CodecAddressFilterArray, PostConstructionInitialization and RequireMaxBusStall

2) I also removed the following sections from AppleHDAPlatformDriver.kext:
CommonPeripheralDSP, Layouts and PathMaps

3) Cleared the caches with my little script (see above).

Yet nothing changed – as in I still got the same / wrong info in System Profiler and System Preferences – Sound. There has got to be either something that I did wrong, or it "just works" but I decided to give up and continue the good deed instead (my time is limited after all).

I first installed StickPin's (shouldn't this be SticMac instead?) LegacyHDAPlatformDriver.kext and changed it (I know, I did it reversed) Layouts (LayoutID to: 883) and PathMaps (PathMapID set to: 883).

I've also been experimenting with PinConfigurations in my HDEF section (example below):

And prior to that by adding the PinConfigurations to my device properties in com.apple.Boot.plist (example snippet below):

Device Properties
Adding the above snippet in raw format won't work of course. No, you'll first need to convert the plist styled XML into HEX code. Let's do that right now, with help of GFXUtil like this:

The next thing would be to import the newly obtained HEX file in EFIStudio, and let it add the new device-properties to your com.apple.Boot.plist with a simple click on a button.

Note: EFIStudio can add device properties to com.apple.Boot.plist for your: Video card, Ethernet (Time Machine) and also HDEF – simply change the layout-id to 883 to make it match the attached files.

System Profiler – tips and misconceptions
Some people think, wrongly, that injecting PinConfigurationswill make their audio work, but that's just a cosmetic thing and actually irrelevant to get your audio working. Again, injecting PinConfigurations like in my example above will only make System Profiler happy i.e. help it show something like this:

Intel High Definition Audio:
Device ID: 0x1043829F
Audio ID: 883
Available Devices:
Line Out:
Connection: 1/8 inch Jack
Microphone:
Connection: 1/8 inch Jack
Microphone:
Connection: 1/8 inch Jack
Headphone:
Connection: 1/8 inch Jack
S/P-DIF Out:
Connection: RCA

However, this is not what we want, because this method won't fix our audio i.e. this way you might end up with either no audio at all, or like me with just one output port working. This of course wasn't good enough for me, especially since my audio already worked, and thus I started to fix things, one after the other. Not that I really use it, but just for the sake of the "hack" part in hackintosh.

Jack Grouping – for System Profiler
Another thing you probably notice is that it only shows one "Line Out:" instead of... say four (8-channel HDA). Well, that's simply because I strictly followed the codec and grouped the ports (Verb Layouts) like this:

This instead of something like:

Watch the red digit: "01x71cx0" which gives you four separate output ports in System Profiler. Resulting in something like:

Intel High Definition Audio:
Device ID: 0x1043829F
Audio ID: 883
Available Devices:
Line Out:
Connection: 1/8 inch Jack
Line Out:
Connection: 1/8 inch Jack
Line Out:
Connection: 1/8 inch Jack
Line Out:
Connection: 1/8 inch Jack
Microphone:
Connection: Internal
Microphone:
Connection: Internal
Line In:
Connection: 1/8 inch Jack
Headphone:
Connection: 1/8 inch Jack
S/P-DIF Out:
Connection: RCA

That's more like it, isn't it – four output jacks (Lime, Orange, Black and Gray) giving you 8-channel HDA – which works here flawlessly and produces an amazing sound. Please note that this is just the start, because I listened to people here and soon realized that things can even be better. It might not be perfect, enough, for you but it is to me.

Changing The Device Order – in System Profiler
The above device order might not suit you – you might like to have your input devices above the output devices. Well, in that case I have good news for you because you can simply change the order by moving "Verb Layouts" (a group of four verbs) in ConfigData which you'll find in your copy of LegacyHDAController.kext For more information about PinComplex, Verb Layouts and Verbs go here.

The Finishing Touch
We jump a few tests and start where I added a modified copy of LegacyHDAPlatformDriver.kext This in order to get audio fully functional – as in the Lime, Orange, Black and Gray output jacks. This Info.plist only kext basically adds the Layouts and PathMaps arrays, which defines the connections between the input/output ports and the on chip mixers. And we need it because I choose to use an undefined layout i.e. 883.

BTW: I was unable to locate the PathMaps with IORegistryExplorer, like in OS X 10.5.6 (I am either missing/overlooking something or this was changed with 10.5.7).

Preliminary conclusions
System Profiler needs PinConfigurations in order to show the audio configuration, and it does this by taking ConfigData from AppleHDAController.kext – it basically reconstructs your codec's Pin Default by taking the last two digits (the lower bits) of each "Verb Layout".

That is when both the layout-id and codec-id match with the hardware, which for my ALC883 wasn't the case and thus I had to inject the correct ConfigData with help of LegacyHDAController.kext (Info.plist only kext).

Injecting ConfigData from within LegacyHDAController.kext only works when AppleHDAController.kext finds PinConfigurations so you have to add this property (a clean one) in your dsdt.dsl like so:

And here's the com.apple.Boot.plist variant (as example):

Both DSDT and com.apple.Boot.plist hacks are just two and the same things, done a little different, but the latter is probably the most easiest way i.e. simpler to grasp for the average Joe OS X users. And this was also the one I first used.

Injected ConfigData and/or PinConfigurations from either dsdt.dsl or com.apple.Boot.plist serves no purpose! At least to me (please correct me if I am wrong).

You got to make sure that your layout-id and codec-id matches in used (modified) files and dsdt.dsl or com.apple.Boot.plist, or things simply won't work i.e. there won't be audio after all.

LegacyHDAController.kext basically overrides the HDAConfigDefault array setup by AppleHDAController.kext and thus there will only be one item (0) instead of fifteen (0 tru 14) in the original 10.5.7 kext.

Troubleshooting
The first thing you want to do when audio won't work, or no longer works after an update, is to check your log files with something like:

or:

And that's how I found the following errors.

Q1: Do you know how we can fix this? If that's a yes... then share it with us. Thank you!

The green front output jack (0x1b/18) in my codec dump is the only place I'm aware of with a reference to "unsolicited" (Unsolicited: tag=04, enabled=1) and thus I removed this specific verb layout from my ConfigData in LegacyHDAController.kext and I also removed it from PathMaps in LegacyHDAPlatformDriver.kext but this did not solve this specific sound assertion. And thus the hunt continues.

Please note that my front panel jacks are not connected to the motherboard because I had no use in this test setup – I will give it a quick try later today.

Credit
There are people I should credit for their work... but I'm not done yet, so it will have to wait for now.

Files
Yet to come... and there might be no need for files after all – Trauma and Boombeng are doing a great job so give their work a try.