Jump to content

AD1984 used in Thinkpad X61 and L61 computers


jacob019
 Share

202 posts in this topic

Recommended Posts

Here's my research so far. Let's all give this some effort and get it sorted out.

 

After installing taruga's ad1986 patch I modified the plist files for AppleHDA.kext and AppleHDAController.kext to match our ad1984 by changing string 299112838 to 299112836. According to ioreg, AppleHDAController and IOHDACodecDevice load fine. The problem is now with IOHDACodecDriver.

 

I've noticed a clever solution at http://forum.insanelymac.com/index.php?showtopic=61513 for a different chip. This guy was stuck at exactly the same point and managed to resolve it. I think we can adapt his method to get our sound working.

 

It seems the next step involves modifying the Info.plist for ALCinject.kext. The layout-id field needs to be changed. It's important to modify the field with a property list editor, as a standard text editor doesn't display it right. Tarugas AD1986 patch has the field set to 13 or 0D000000 in hex. Based on the work of macdanger it seems we just need to try many values sequentially until one loads the driver. After we load the driver successfully then we can move on to fixing the codec.

 

The datasheet for our AD1984 can be found at: http://www.analog.com/UploadedFiles/Data_Sheets/AD1984.pdf

The linux codec dump is attached.

 

Post your thoughts and results here. We can do it!

 

Jacob

codec.txt

Link to comment
Share on other sites

Let's do this.

 

can you upload the modiefied AppleHDA.kext (modified so far) so we can work on it?

 

And, after sequentially trying all the values for layout-id, do we do ioreg to see if the driver is working?

 

I will try to look around to see what I can do. But yes, we need sound for X61. One step closer to completely functioning Mac.

Link to comment
Share on other sites

Popophobia,

 

Here's my AppleHDA.kext, the codec will still need some work. I've also included a few lines from "ioreg -l". These devices are nested sequentially. Notice how everything load up until IOHDACodecDriver where it says !registered, !matched (! meaning not). You may also notice that there is IOHDACodecDevice@0 and IOHDACodecDevice@1, we are only concerned with IOHDACodecDevice@0, the other one is the modem I believe. I believe we need to get ALCinject working first. Keep me posted.

 

AppleHDAController <class AppleHDAController, registered, matched, active, busy 0, retain 7>

IOHDACodecDevice@0 <class IOHDACodecDevice, registered, matched, active, busy 0, retain 6>

IOHDACodecDriver <class IOHDACodecDriver, !registered, !matched, active, busy 0, retain 5>

IOHDACodecFunction@1 <class IOHDACodecFunction, registered, matched, active, busy 0, retain 4>

 

This laptop really kicks ass as a hackintosh, everything's working great for me except audio and SpeedStep. I put in an atheros wifi card today and it works just like an airport express! If we get audio going we'll have the perfect machine. I'd buy a MacBook if they made them in 12"

AppleHDA.kext.zip

Link to comment
Share on other sites

  • 2 months later...

Hey,

I found out something today. If you play a song in OS X and unplug the AC adapter, there's a short burst of sound from the speaker. Maybe there is something wrong with the power management control of HDA kext file.

 

I installed Azalia patch and was able to get the volume control (and this weird behaviour).

 

Here's part of the ioreg output

 

	| |   | +-o AppleAzaliaController  <class AppleAzaliaController, registered, matched, active, busy 0, retain 8>
| |   |   | {
| |   |   |   "IOProviderClass" = "IOPCIDevice"
| |   |   |   "IOProbeScore" = 0
| |   |   |   "CFBundleIdentifier" = "com.apple.driver.AppleAzaliaController"
| |   |   |   "IOMatchCategory" = "IODefaultMatchCategory"
| |   |   |   "IOPCIPrimaryMatch" = "0x26688086 0x27d88086 0x284b8086 0x32881106 0x026c10de 0x037110de 0x03e410de 0x03f010de 0x044a10de 0x044b10de 0x437b1002 0x43831002 0x75021039"
| |   |   |   "IOPowerManagement" = {"ChildrenPowerState"=2,"CurrentPowerState"=2}
| |   |   |   "IOClass" = "AppleAzaliaController"
| |   |   | }
| |   |   | 
| |   |   +-o IOHDAudioCodecDevice@0  <class IOHDAudioCodecDevice, registered, matched, active, busy 0, retain 6>
| |   |   | | {
| |   |   | |   "IOHDAudioCodecVendorID" = 299112836
| |   |   | |   "IOHDAudioCodecRevisionID" = 1049600
| |   |   | | }
| |   |   | | 
| |   |   | +-o IOHDAudioCodecDriver  <class IOHDAudioCodecDriver, !registered, !matched, active, busy 0, retain 5>
| |   |   |   | {
| |   |   |   |   "IOProviderClass" = "IOHDAudioCodecDevice"
| |   |   |   |   "IOProbeScore" = 0
| |   |   |   |   "IOMatchCategory" = "IODefaultMatchCategory"
| |   |   |   |   "IOClass" = "IOHDAudioCodecDriver"
| |   |   |   |   "CFBundleIdentifier" = "com.apple.iokit.IOHDAudioFamily"
| |   |   |   | }
| |   |   |   | 
| |   |   |   +-o IOHDAudioCodecFunction@1  <class IOHDAudioCodecFunction, registered, matched, active, busy 0, retain 6>
| |   |   |	 | {
| |   |   |	 |   "IOHDAudioCodecFunctionSubsystemID" = 397025501
| |   |   |	 |   "IOHDAudioCodecFunctionGroupType" = 1
| |   |   |	 | }
| |   |   |	 | 
| |   |   |	 +-o AppleAzaliaAudioCodecGeneric  <class AppleAzaliaAudioCodecGeneric, registered, matched, active, busy 0, retain 10>
| |   |   |	   | {
| |   |   |	   |   "IOProviderClass" = "IOHDAudioCodecFunction"
| |   |   |	   |   "IOProbeScore" = 0
| |   |   |	   |   "IOMatchCategory" = "IODefaultMatchCategory"
| |   |   |	   |   "IOHDAudioCodecFunctionGroupType" = 1
| |   |   |	   |   "IOClass" = "AppleAzaliaAudioCodecGeneric"
| |   |   |	   |   "CFBundleIdentifier" = "com.apple.driver.AppleAzaliaAudio"
| |   |   |	   | }
| |   |   |	   | 
| |   |   |	   +-o AppleAzaliaAudioDriver  <class AppleAzaliaAudioDriver, registered, matched, active, busy 0, retain 6>
| |   |   |		 | {
| |   |   |		 |   "IOProbeScore" = 0
| |   |   |		 |   "IOAudioDeviceManufacturerName" = "Apple"
| |   |   |		 |   "InputSampleLatency" = 30
| |   |   |		 |   "CFBundleIdentifier" = "com.apple.driver.AppleAzaliaAudio"
| |   |   |		 |   "IOMatchCategory" = "IODefaultMatchCategory"
| |   |   |		 |   "IOPowerManagement" = {"CurrentPowerState"=1,"DriverChangePowerState"=1}
| |   |   |		 |   "IOAudioDeviceShortName" = "Built-in"
| |   |   |		 |   "IOProviderClass" = "AppleAzaliaAudioCodec"
| |   |   |		 |   "IOAudioDeviceCanBeDefaults" = 7
| |   |   |		 |   "IOAudioDeviceTransportType" = 1651274862
| |   |   |		 |   "IOAudioDeviceName" = "Built-in Audio"
| |   |   |		 |   "IOAudioDeviceModelID" = "AppleAzaliaAudioDriver:Built-in Audio"
| |   |   |		 |   "SampleOffsetPad" = 0
| |   |   |		 |   "IOClass" = "AppleAzaliaAudioDriver"
| |   |   |		 |   "OutputSampleLatency" = 30
| |   |   |		 | }
| |   |   |		 | 
| |   |   |		 +-o AppleAzaliaAudioEngineOutput  <class AppleAzaliaAudioEngineOutput, registered, matched, active, busy 0, retain 21>
| |   |   |		   | {
| |   |   |		   |   "IOAudioEngineOutputSampleLatency" = 30
| |   |   |		   |   "IOAudioEngineDescription" = "HD Audio Output"
| |   |   |		   |   "IOAudioEngineNumActiveUserClients" = 0
| |   |   |		   |   "IOAudioEngineNumSampleFramesPerBuffer" = 16384
| |   |   |		   |   "IOAudioEngineSampleOffset" = 32
| |   |   |		   |   "IOAudioEngineClockDomain" = 87819776
| |   |   |		   |   "IOAudioEngineState" = 0
| |   |   |		   |   "IOAudioEngineFlavor" = 1
| |   |   |		   |   "IOAudioEngineGlobalUniqueID" = "AppleAzaliaAudioEngineOutput:0"
| |   |   |		   |   "IOAudioSampleRate" = {"IOAudioSampleRateFraction"=0,"IOAudioSampleRateWholeNumber"=44100}
| |   |   |		   |   "IOAudioEngineInputSampleLatency" = 30
| |   |   |		   |   "IOGeneralInterest" = "IOCommand is not serializable"
| |   |   |		   | }

Link to comment
Share on other sites

  • 2 weeks later...

I think our best bet is to try and get Taruga to personally look at it on his forum. I'm really hoping that we'll be able to get this.... an entire notebook manufacturer (Lenovo) uses this chip for their portables... he'd be helping a lot of people!

 

I read somewhere that there was some info about the card buried in 10.5.3 but I haven't updated yet. Anybody familiar?

 

Taruga's wiki is here:

 

http://wiki.taruga.net/

 

Sign up and make some noise!

Link to comment
Share on other sites

jacob,

 

Have you tried these things under 10.5.3? I get some different behaviour with the AD1984 and I hear that there is some mention of the codec in native OSX code. If not, can you tell me what to do so I can keep atempting things?

 

Thanks much!

Link to comment
Share on other sites

According to : http://www.thinkwiki.org/wiki/AD1984

 

the AD1984 shares a bus with the modem... I'm not entirely sure what they are talking about in that Wiki, but it seems that in whatever OS they are talking about the sound card would not work until the modem was initialized..... I haven't tried it, but do our modems work? Are they initialized at all?

Link to comment
Share on other sites

ALSA is for linux sound. From what I gather, they're just saying that you can't disable the modem in the bios without affecting the sound. It shouldn't matter for us, you don't actually need modem drivers loaded, and the hardware is definitely initialized as it shows up in ioreg.

Link to comment
Share on other sites

Got it. I installed your modified AppleHDA.kext in 10.5.3, and it takes away the functionality of the volume buttons. Additionally all media plays for about two seconds and then stops. I know it wasn't a completed HDA or anything whatsoever, I'm just trying to see what was modified and where to go from here. I have a lot of time on my hands at this point, and I'd like to try whatever I can-- I'm just not entirely sure on where to start.

Link to comment
Share on other sites

Here's my research so far. Let's all give this some effort and get it sorted out.

 

After installing taruga's ad1986 patch I modified the plist files for AppleHDA.kext and AppleHDAController.kext to match our ad1984 by changing string 299112838 to 299112836. According to ioreg, AppleHDAController and IOHDACodecDevice load fine. The problem is now with IOHDACodecDriver.

 

I've noticed a clever solution at http://forum.insanelymac.com/index.php?showtopic=61513 for a different chip. This guy was stuck at exactly the same point and managed to resolve it. I think we can adapt his method to get our sound working.

 

It seems the next step involves modifying the Info.plist for ALCinject.kext. The layout-id field needs to be changed. It's important to modify the field with a property list editor, as a standard text editor doesn't display it right. Tarugas AD1986 patch has the field set to 13 or 0D000000 in hex. Based on the work of macdanger it seems we just need to try many values sequentially until one loads the driver. After we load the driver successfully then we can move on to fixing the codec.

 

The datasheet for our AD1984 can be found at: http://www.analog.com/UploadedFiles/Data_Sheets/AD1984.pdf

The linux codec dump is attached.

 

Post your thoughts and results here. We can do it!

 

Jacob

 

 

I just want to get this straight so I can start getting some work done.

 

So the first thing that I did was install Taruga's 1986 patch. Then I changed 299112838 to 299112836. Just curious -- but where does this number come from? In any case, after I did that, I open up Info.plist in ALCinject.kext and sequentially change the layout-id field? How am I sure that the driver loads? ALCInject.kext will appear in ioreg? Sorry, macdanger's post didn't really lead me to understand what was going on.

 

Nevertheless what numbers have you tried in ALCInject's plist? I'm sure we would have a legion of people behind us trying different things if there are more clear-cut instructions :)

 

Thanks!

Link to comment
Share on other sites

I'm pleased that you're interested. 299112836 is the decimal equivalent of 11d41984 (the vendor id and product code for our device). Type "ioreg -l" into the terminal. This lists all the hardware and how it's connected, similar to windows device manager in tree view, but with more detail. Look for AppleHDAController. This is where macos recognizes our audio hardware device. Several subnodes must be connected to it in order to have usable audio. Even after the hardware is all properly recognized, we will have to adjust the codec so that the driver can speak the proper language to the audio chip. The goal right now is just to make the audio chip recognized completely, after that we may still have broken audio, but we should hear something from the speaker when sound is played, even if it is all garbled. The subnodes in my ioreg output are:

| | | +-o AppleHDAController <class AppleHDAController, registered, matched, active, busy 0, retain 7>

| | | +-o IOHDACodecDevice@0 <class IOHDACodecDevice, registered, matched, active, busy 0, retain 6>

| | | | +-o IOHDACodecDriver <class IOHDACodecDriver, !registered, !matched, active, busy 0, retain 5>

| | | | +-o IOHDACodecFunction@1 <class IOHDACodecFunction, registered, matched, active, busy 0, retain 4>

| | | +-o IOHDACodecDevice@1 <class IOHDACodecDevice, registered, matched, active, busy 0, retain 6>

 

there are more detals listed but this is the gist of it. The last line IOHDACodecDevice@1 represents our modem, this should be ignored. Notice how lines all say registered, matched except IOHDACodecDriver? If your output is like this than you've gotten as far as I have. Macdanger was able to get IOHDACodecDriver loaded for his unsupported card. Changing tarugas driver gets us this far, but working on ALCinject.kext should get IOHDACodecDriver working. It will be a tedious process, with many reboots, and I'm not even 100% confident that it will work, but macdanger made it work.

 

To see if you're successful type "ioreg -l|grep IOHDACodecDriver"

we only care about the first line, if you are successful then !resgistered, !matched will turn into registered, matched

 

Jacob

Link to comment
Share on other sites

I know I'm going to sound like a complete idiot here (sorry for that-- I do know my way around things I'm just a bit confused here), but I don't seem to even have IOHDACodecDevice.kext at all. I don't have any IOHDA* kext's whatsoever. I've looked in AppleHDA.kext for them (but I was pretty sure they were full extensions), but to no avail. Typing that command in Terminal shows absolutely nothing.

 

10.5.2 iAtkos vanilla kernel install, with kaly combo update to 10.5.3. Would you be able to upload it at all if possible?

 

Oh yes, and FINALLY: I'm editing with Apple's Property List Editor. The layout-id is written as a data class, and the value is <0c000000>. I have no clue what to convert this to, or how to convert it to numbers that make sense to me.

 

I assumed it was hexadecimal to decimal like this:

 

http://www.statman.info/conversions/hexadecimal.html

 

But that converts 0c000000 to a gigantic number. I'd appreciate any help. And what should I start at? 1 - ... sky's the limit? 0? Thanks for holding my hand through this.

 

Edit: I'm going right back to stock 10.5.2 so I can start over (I am pretty sure my Extension folder is messed up).

Link to comment
Share on other sites

Alright... after having some issues I finally got back to 10.5.2, and was able to get started.

 

I've done decimal values from 00-53 (00 to 35 in hex) so far and nothing has turned the '!matched' to 'matched'. What are the range of numbers that it could possibly be? What numbers have you tried?

 

If anybody is interested in getting a chunk of numbers done, post up here what you're interested in doing! Be sure to follow the first post in this topic.

 

My system is as follows: Have an ALCInject.kext on the desktop that is owned by the current user (so it can be edited out of command line). I had Property List Editor, Terminal, and kext helper all open at startup. Upon startup, I would run the command to check and see if IOHDACodecDriver was matched. When I found it wasn't, I would open-->recent ALCInject.kext on the desktop.... edit the layout-id field to the next sequential one then save it. I would drag that kext into kext helper and run that. That replaces ALCinject, changes the permissions back to root only, and also touches Extensions.mkext in order to reload each boot.

 

Anyways like I said this system worked well-- but alas I have not gotten any results yet.

Link to comment
Share on other sites

I always use layout id = 12 not 13. It can be any number, that's not important if the layout id and path maps are linked to the layout id.

It seems the next step involves modifying the Info.plist for ALCinject.kext. The layout-id field needs to be changed. It's important to modify the field with a property list editor, as a standard text editor doesn't display it right. Tarugas AD1986 patch has the field set to 13 or 0D000000 in hex. Based on the work of macdanger it seems we just need to try many values sequentially until one loads the driver. After we load the driver successfully then we can move on to fixing the codec.
No need for translation, it´s a copy of one of my posts here at Insanely Mac
Got it. I'll try it out to see how I can do it.So, after changing the kext file and fixing permission, do we have to reboot or is a kextload command sufficient?Found this:http://x86osx.com/bbs/view.php?id=freeboar...7c39bc46e3a6e0fSeems like 1984 support is on the way.(you can use google translate)
Link to comment
Share on other sites

 Share

×
×
  • Create New...