61 replies to this topic

[Master Chief]

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.photobuc...und-outputs.png
http://i639.photobuc...ound-inputs.png

Audio MIDI Setup:
http://i639.photobuc...midi-output.png
http://i639.photobuc.../midi-input.png

IORegistryExplorer:
http://i639.photobuc.../ioref-hdef.png
http://i639.photobuc...AController.png
http://i639.photobuc...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:

ioreg -lw0 | grep DSDT > ~/Desktop/ioregdump.txt

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:

./Tools/iasl -d dsdt.dat

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

cd /Applications/Utilities/Tools/DSDTPatcher
 sudo nano dsdt.dsl

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.

Device (HDEF)
{
	Name (_ADR, 0x001B0000)
	Method (_PRW, 0, NotSerialized)
	{
		Return (Package (0x02)
		{
			0x0D, 
			0x05
		})
	}
			  
	Method (_DSM, 4, NotSerialized)
	{
		Store (Package (0x0A)
		{
			"built-in",
			Buffer (One)
			{
				0x00
			},
				 
			"codec-id",
			Buffer (0x04)
			{
				/* 0x10EC0883/283904131 */	0x83, 0x08, 0xEC, 0x10
			},
					 
			"layout-id",
			Buffer (0x04)
			{
				/* 883 */	0x73, 0x03, 0x00, 0x00
			},
			
			"device-type",
			Buffer (0x10)
			{
				"Realtek ALC883"
			},

		   "PinConfigurations",
		   Buffer (0x01)
		   {
			   0x00
		   }

		}, Local0)
		DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
		Return (Local0)
	}
}

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)

Method (DTGP, 5, NotSerialized)
{
	If (LEqual (Arg0, Buffer (0x10)
		{
		/* 0000 */	0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44,
		/* 0008 */	0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B
		}))
	{
		If (LEqual (Arg1, One))
		{
			If (LEqual (Arg2, Zero))
			{
				Store (Buffer (One)
				{
					0x03
				}, Arg4)
				Return (One)
			}
				 
			If (LEqual (Arg2, One))
			{
				Return (One)
			}
		}
	}
			 
	Store (Buffer (One)
	{
		0x00
	}, Arg4)
	Return (Zero)
}

Ok.  Time to re-compile dsdt.dsl:

sudo ./Tools/iasl 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:

sudo cp dsdt.aml /dsdt.aml
 sudo 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:

1) open a terminal window and enter:
2) sudo cp /boot /boot.backup
3) sudo cp /~Desktop/chameleon/chameleon /boot

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

sudo touch /S*/L*/Extensions.mkext
sudo touch /S*/L*/Extensions
sudo reboot

For Snow Leopard 10.6.x installations

sudo kextcache -v 1 -t -l -m /Extra/Extensions/Extensions.mkext /Extra/Extensions /Extra/Extensions
sudo kextcache -v 1 -t -l -m /S*/L*/Caches/com.apple.kext.caches/Startup/Extensions.mkext /S*/L*/Extensions

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):

"PinConfigurations", 
Buffer (0x2f)
{
	/* 0000 */   0x10, 0x40, 0x01, 0x01, 0x10, 0x10, 0x01, 0x01,
	/* 0008 */   0x10, 0x60, 0x01, 0x01, 0x10, 0x20, 0x01, 0x01,
	/* 0010 */   0x40, 0x98, 0xa1, 0x90, 0x50, 0x9c, 0xa1, 0x02,
	/* 0018 */   0x40, 0x30, 0x81, 0x01, 0x20, 0x4c, 0x21, 0x02,
	/* 0020 */   0xf0, 0x01, 0x33, 0x59, 0x00, 0xe6, 0x15, 0x40,
	/* 0028 */   0x30, 0x11, 0x44, 0x01, 0xf0, 0x11, 0x11, 0x41
}

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

<key>PciRoot(0x0)/Pci(0x1b,0x0)</key>
	<dict>
		<key>built-in</key>
		<string>0x00</string>
		<key>PinConfigurations</key>
		 <data>EEABARAQAQERYAEBECABAUCYoZBQnKECQDCBASBMIQLwATNZAOYVQDARRAHwERFB</data>
		<key>layout-id</key>
		<string>0x00000373</string>
	</dict>

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:

sudo gfxutil -s -n -i xml -o hex in.xml out.hex

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:

01471c10 01471d40 01471e01 01471f01
01571c10 01571d10 01571e01 01571f01
01671c10 01671d60 01671e01 01671f01
01771c10 01771d20 01771e01 01771f01

This instead of something like:

01471c10 01471d40 01471e01 01471f01
01571c20 01571d10 01571e01 01571f01
01671c30 01671d60 01671e01 01671f01
01771c40 01771d20 01771e01 01771f01

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:

"PinConfigurations",
Buffer (Zero)
{
}

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

<key>PinConfigurations</key>
<string></string>

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:

sudo dmesg|grep "Sound assertion"

or:

cat /var/log/system.log|grep "Sound assertion"

And that's how I found the following errors.

Jun 17 11:48:46 Chief kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-168.1.3/AppleHDA/AppleHDAWidget.cpp" at line 2514 goto handler
Jun 17 11:48:46 Chief kernel[0]: Sound assertion "0 != widget->setUnsolicited ( true )" failed in "/SourceCache/AppleHDA/AppleHDA-168.1.3/AppleHDA/AppleHDACodecGeneric.cpp" at line 855 goto handler

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.

[VCH888]

@Master Chief


change 0x40, 0x98, 0xa1, 0x01 to 0x40, 0x98, 0xa1, 0x90 for getting Internal microphone, not none.

[Master Chief]

tmongkol, on Jun 17 2009, 01:25 PM, said:

@Master Chief
change 0x40, 0x98, 0xa1, 0x01 to 0x40, 0x98, 0xa1, 0x90 for getting Internal microphone, not none.

I changed it in both snippets but I don't have a PinConfigurations setup anywhere – see my first post.

Hm, maybe I should give it another try with my PinConfigurations and see what happens.

Thanks!

[Trauma!]

Hy Master Chief,

Injecting ConfigData or PinConfig via DSDT is useless since it's overrided by the plist. I don't see the point of removing things from the vanilla plist when they can be overrided by a plist kext.

By the way very clear explaination of your work that's will certainly help lot of people to understand this procedure.

What you can do is build one plit with HDAController and HDAPlatformDriver moded inside.

This is what i did with my freind Boombeng : http://files.getdrop...jector.kext.zip

It's use HDAEnabler, but it can be simply replaced by DSDT or device property string.

Bye.

[Master Chief]

Trauma!, on Jun 19 2009, 11:49 PM, said:

Injecting ConfigData or PinConfig via DSDT is useless since it's overrided by the plist.

Absolutely, but I guess that I wasn't clear enough, and thus I changed the text a bit.

Trauma!, on Jun 19 2009, 11:49 PM, said:

I don't see the point of removing things from the vanilla plist when they can be overrided by a plist kext.

That was for testing only, because at the time I didn't use anything but the vanilla AppleHDA kext and yet audio worked
and showed up in System Preferences, so I had to figure out what it was.

Trauma!, on Jun 19 2009, 11:49 PM, said:

By the way very clear explaination of your work that's will certainly help lot of people to understand this procedure.

Thanks you very much.  That was the purpose yes.

Trauma!, on Jun 19 2009, 11:49 PM, said:

What you can do is build one plit with HDAController and HDAPlatformDriver moded inside.
This is what i did with my freind Boombeng : http://files.getdrop...jector.kext.zip
It's use HDAEnabler, but it can be simply replaced by DSDT or device property string.

I will look into it, but I don't want to use HDAEnabler.kext anymore.  Might still be worth the trouble though (I might want to add it later on).  Thanks!

[Boombeng]

Hi Masterchief

Does your patched appleHDA enable Front mic and Grey line out ? because it is not working with ours  

For the moment it is only tested with P5K-se but may be it works also with other P5K

http://www.insanelym...p...t&p=1181846

cheers

[Trauma!]

Master Chief, on Jun 20 2009, 01:35 AM, said:

Absolutely, but I guess that I wasn't clear enough, and thus I changed the text a bit.
That was for testing only, because at the time I didn't use anything but the vanilla AppleHDA kext and yet audio worked
and showed up in System Preferences, so I had to figure out what it was.
Thanks you very much.  That was the purpose yes.
I will look into it, but I don't want to use HDAEnabler.kext anymore.  Might still be worth the trouble though (I might want to add it later on).  Thanks!

Hi,

Glade to see we are 100 % agree.    

About my plist kext, i used HDAEnabler.kext in order to make this kext, and his little brothers, easy to use for most of us. I think too that injecting HDEF via DSDT or string is the best way.

But what i regret the most is that we can't actually make a plist with several codecs inside. Since HDAEnabler and ohter injection methods use LayoutID to select the codec.

Cheers.

[Master Chief]

Boombeng, on Jun 20 2009, 09:57 AM, said:

Does your patched appleHDA enable Front mic and Grey line out ? because it is not working with ours  

I haven't had a change to check the microphone inputs, but I have 8-channel HDA audio working on the Lime, Orange, Black and Gray output jacks yes.

p.s. I will upload the files when I'm done testing.

EDIT: My microphone doesn't seem to be working anymore so I'll first have to get a new one on Monday before I can test the line-in and microphone jacks.

EDIT 2: The new microphone works, but input level might need a little push.

[zhell]

Master Chief, on Jun 20 2009, 07:15 PM, said:

I haven't had a change to check the microphone inputs, but I have 8-channel HDA audio working on the Lime, Orange, Black and Gray output jacks yes.

p.s. I will upload the files when I'm done testing.

EDIT: My microphone doesn't seem to be working anymore so I'll first have to get a new one on Monday before I can test the line-in and microphone jacks.

EDIT 2: The new microphone works, but input level might need a little push.

Very clear explanation, Master Chief, thanks so much!
For the record (no pun intended) you can easily plug in a pair of earphones into the mic port and this should give you enough of a signal. In my experience it provides a higher signal level than the mics of most headsets.

[Boombeng]

Hi MasterChief

I made some tests to enable Grey Line out and Front mic, and I managed to make them work BUT when grey line out is enabled there is no more SPDIF out and to enable front mic I have to disable Rear Mic  

[aliasa_anderson]

Hi Master Chief,

Did you try the VoodooHDA.kext for your sound.
I know this thread is for AppleHDA,just wanted to update you and know your views regarding the same.
Also i wanted to know if AppleHDA mod would work on Conexant chips(i have Vanice core) and would the DSDT method help me display the audio properties in system profiler,i mean is it independent of the kext you use - AppleHDA vanilla/moded or VoodooHDA or perhaps AppleAzalia.

Thanks in advance.

[Master Chief]

zhell, on Jun 22 2009, 11:16 PM, said:

Very clear explanation, Master Chief, thanks so much!

Thank you, and there will be even more added one day soon.

zhell, on Jun 22 2009, 11:16 PM, said:

For the record (no pun intended) you can easily plug in a pair of earphones into the mic port and this should give you enough of a signal.  In my experience it provides a higher signal level than the mics of most headsets.

Really?   You mean like the onces I have for my iPod and iPhone?  Let me try that tomorrow.  Thanks.

Boombeng, on Jun 23 2009, 12:04 AM, said:

Hi MasterChief

I made some tests to enable Grey Line out and Front mic, and I managed to make them work BUT when grey line out is enabled there is no more SPDIF out and to enable front mic I have to disable Rear Mic  

Jo Boombeng,

Great to see you make progress on your own, but I'm a but confused about the: "no more SPDIF out" (which I BTW though wasn't verified to work in your kext)  and "to enable front mic I have to disable Rear Mic" parts.   What does that mean?
You have to change ConfigData or remove items under PathMap?

I don't have a front Mic jack right now, but that can be arranged tomorrow.

aliasa_anderson, on Jun 23 2009, 12:23 AM, said:

Hi Master Chief,

Did you try the VoodooHDA.kext for your sound.

No I didn't.   I guess that the reference to "voodoo" alone was too much for me.  Nah, I'm just an old geezer doing things the wrong way, battling uphill instead of going with the flow – which FYI is what makes me learn new stuff.

aliasa_anderson, on Jun 23 2009, 12:23 AM, said:

Also i wanted to know if AppleHDA mod would work on Conexant chips(i have Vanice core) and would the DSDT method help me display the audio properties in system profiler,i mean is it independent of the kext you use - AppleHDA vanilla/moded or VoodooHDA or perhaps AppleAzalia.

Just to be clear; we do not modify the original, vanilla AppleHDA.kext here, but use LegacyHDAController.kext and LegacyHDAPlatformDriver.kext instead – one of the goals here is to stay away from modifying the original kext files.

Also, System Profiler will report all in- and output jacks when sound works, and thus there is no need to inject it via PinConfigurations  or ConfigData – which is what System Profiler uses.

I'm afraid that I have to skip the most important part of your question, simply because I have no idea.  Sorry.

[Boombeng]

Jo

Master Chief, on Jun 23 2009, 02:03 AM, said:

I'm a but confused about the: "no more SPDIF out" (which I BTW though wasn't verified to work in your kext)

After adding Nodes for Grey Out (23 15 5) (also need to put the 2 switching green out, front 27 38 37  and rear 20 12 2, under the same pathmap level) the SDPDIF out disappeared from Sound PrefPan, but I didn't test if it worked before and after

Master Chief, on Jun 23 2009, 02:03 AM, said:

and "to enable front mic I have to disable Rear Mic" parts.   What does that mean?
You have to change ConfigData or remove items under PathMap?

In fact to have a working frony mic I removed blue line in items from PathMap (8 35 26) and changed Front Mic Port  from 9 to 0 in Config Data so that "No device" message in Sounf prefpan appears instead of InternalMic
ExtMic needs to be added in layOut also

Cheers

[Trauma!]

Hey guys,

As far as i know AppleHDA.kext can only handle 4 stereo outputs Channels at the same time. So Boombeng, the fact you've lost SPDIF output is totaly normal.

And as you've said, boombeng, in order to have 4 stereo analog outputs + headphones, you have to bundle the headphone and the first line output together under the same array.

About inputs, it's look like ther is a limitation too, "i guess" more than 3 inputs is not possible. Let's try to delete all digital I/O and you should be able to have all analog ports working.

Personnaly i'm more interested in SPDIF (Dolby Digital & DTS) than all analogs ports....

Apple computers has never used as much audio I/O as we do

Cheers.

[Boombeng]

Here is a new version with front Mic and all analog outputs at rear (including Grey one)  

http://www.insanelym...p...t&p=1184119

Cheers

[Trauma!]

Hi All,

After several testing it's appear that it's not possible to have more than 2 analogs inputs at the same time with the latest AppleHDA.

So Boombeng and I have decided to bundle the front two mic and the line in (rear) inside the same array and use the "DetectDelegate" string to enable automatic switching between rear & front inputs.

And guess what ? It worked We now have an all analog I/O working plist for ALC883 with jack override between front and rear I/O's.

We will release that soon.

Cheers,

Darwinx86 Team

[THe KiNG]

Master Chief, on Jun 23 2009, 04:03 AM, said:

........

Also, System Profiler will report all in- and output jacks when sound works, and thus there is no need to inject it via PinConfigurations  or ConfigData – which is what System Profiler uses.

.....

Wrong!

System Profiler  report all input and output jacks when you use hdaenabler b/c it injects PinConfigurations look on hdaenabler plis, you will see PinConfigurations <>, and you can inject the same thing in dsdt...all it needs is <>

About outputs/inputs
4 max analog out can be defined one of them must be on switch(eg HP)
3 max analog inputs can be defined one of them must be on switch(eg LineIn with Back/or Front Mic)
Dunno about digital one i cant test them here but so far looks ok

About mic, the main problem is that you cant add as example in platform plist Mic1/Mic2 etc
So one of them cant use correct MuteGPIO, and the result is bad signal or not working at all
Apple did use ExtMic but that is an ACPIHeadset, and using that would lead to fmikey error and in some case no mic working at all..

So my conclusions so far:
7.1 analog out will never work with applehda, 5.1 is the best you can get
One of the mics have to be sacrified, i dithced back one...line in is enough and mic + headphones on front.

Hope this help.

Cya.

[Master Chief]

THe KiNG, on Jun 23 2009, 09:38 PM, said:

Wrong!

System Profiler  report all input and output jacks when you use hdaenabler b/c it injects PinConfigurations look on hdaenabler plis, you will see PinConfigurations <>, and you can inject the same thing in dsdt...all it needs is <>

Not exactly:  Yes, System Profiler utilizes PinConfigurations... but it doesn't matter where it comes from.  And I don't use HDAEnabler.kext (see title) neither do I inject the PinConfigurations nor ConfigData from dsdt.aml or com.apple.Boot.plist– maybe I wasn't clear enough, but that's all I was addressing.  Nothing more.

THe KiNG, on Jun 23 2009, 09:38 PM, said:

So my conclusions so far:
7.1 analog out will never work with applehda, 5.1 is the best you can get
One of the mics have to be sacrified, i dithced back one...line in is enough and mic + headphones on front.

So how do you call 8-channel audio?  To me that is 7.1 – and looking at the HDA specifications I am right.  And boy does that sound great!

[Master Chief]

Trauma!, on Jun 23 2009, 07:33 PM, said:

Hi All,

After several testing it's appear that it's not possible to have more than 2 analogs inputs at the same time with the latest AppleHDA.

The magic is behind: "it appears" as in don't bet you life on it, but keep "thinking out of the box"

Trauma!, on Jun 23 2009, 07:33 PM, said:

So Boombeng and I have decided to bundle the front two mic and the line in (rear) inside the same array and use the "DetectDelegate" string to enable automatic switching between rear & front inputs.

And guess what ? It worked We now have an all analog I/O working plist for ALC883 with jack override between front and rear I/O's.

Great work, but I'm not surprised.  Not at all, since it works here – and that was of course one of the reasons for writing this tutorial.

Nonetheless, great to see you guys reporting your findings here, so that people know that it can be done – I'm planning my vacation and that takes a lot of time for six people you know, so I'll be slow one more time.  Sorry guys.  Keep up the good work!

[THe KiNG]

Master Chief, on Jun 24 2009, 01:23 AM, said:

Not exactly:  Yes, System Profiler utilizes PinConfigurations... but it doesn't matter where it comes from.  And I don't use HDAEnabler.kext (see title) neither do I inject the PinConfigurations nor ConfigData from dsdt.aml or com.apple.Boot.plist– maybe I wasn't clear enough, but that's all I was addressing.  Nothing more.
So how do you call 8-channel audio?  To me that is 7.1 – and looking at the HDA specifications I am right.  And boy does that sound great!

Your are speaking only for your specific codec...
Apple don't give a sh*t on specifications, they don't use analog surround out only digital so anyway getting surround working is kind of lame b/c itunes or other apple app will not gave u more then 2ch out(vlc works if the input is 5.1), so you can sit and watch how nice is to play stereo *4.
I didn't tried to add more then 5.1 ch on 10.5.7(or 5.8) applehda, my focus was to get the rest of inputs/outputs working proper and they are...
So I'm curious if the rest of inputs/outputs works for you with 7.1 out....

BTW Trauma! & Boombeng nice findings! Keep up the good work!