AD1984 used in Thinkpad X61 and L61 computers, let's sort this one out Options

[jacob019]

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

[mulletman13]

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

[mulletman13]

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.

[Taruga]

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)

[jacob019]

I'm honored to see a post from Taruga in this thread. It seems we need to study up on path maps. Thank you Targua!

[Taruga]

You can try the layout-ids you want.... apple doesn't use ad1984, nor the driver is ready for it. So, it won´t match any layout-id´s as all of them were made for sigmatel and realtek.
You can force things up but the result and work in the way can be disappointing.
AD198x codecs are very different than other audio codecs apple uses, they require powering up some nids and the driver doesn't seem to do it by itself.
My best successful attempt to get AD198x working was with AD1988b, and it took me more than a month. I had to use codec programming as I did with a few other codecs before.
One thing that you have in advantage is having the codec to try with.... as it will require lots, and lots of attempts to get any result .... if any you will get.
Some codec I´ve fixed in a couple of hours, others in a couple of days, others in a month (like ad1988b) and others in a couple of months (like ALC861 for F3JC notebook).
And with AD1988b I really had to buy a board just to get it thru, else I would be testing this one with users for about a year, and even with it to test... it took a month

PS- You all are forgetting the importante stuff ... AppleHDAController ConfigData property where the codec programing goes.
And to understand it, you´ll need HDA Intel Specification Reference Manual as well as the Codec Datasheet... and you must think like a computer and not like a human

[jacob019]

Thank you for the great info Taruga, it will help us move in the right direction. Unfortunately our datasheet (found here) provides less info than other 198X chips, but it will help. Is there anything we can do to force IOHDACodecDriver to be recognized for testing purposes?

[popophobia]

Hi all, I'm installing OS X 10.5.2 on a separate hdd to test this. Hopefully we can get this done soon.

Glad that this topic is active again

[T u r b o]

Hey all,

I've worked with Taruga a bit on getting the AD1984 in my T61 working, and thanks to some of his insights I can get all components matched/loaded with the 10.5.2 driver. There is still no sound - the driver complains about the nodes being powered down (D3 state).

I wrote a script to generate config-data that should power up all nodes but it's still not making the driver happy:

CODE

Sound assertion "( ( kIOAudioDeviceActive != fCurrentPowerState ) && ( kAppleHDAIOAudioDeviceForcedActive != fCurrentPowerState ) )" failed in "/SourceCache/AppleHDA/AppleHDA-156.1.19/AppleHDA/AppleHDAEngine.cpp" at line 653 goto Exit

It should be possible to patch the driver to get everything powered up.

- Turbo

[Riotz]

You guys are doing awesome work here. I hope you are successful so that everyone who is stuck without sound on this chip has a way out. I am definitely going to track this topic.

Cheers

Riotz

[jacob019]

Great work turbo! Could you post your work thus far?

[mulletman13]

Glad to hear it Turbo! VERY excited this topic is active again! Let's push it until we get it running!

Oh and Taruga -- if you ever need to VNC into my machine or anything I'm always available (as are other people here). Some of these things are beyond the scope of my understanding, but I'll read up on it and try to help however I can.

.... then perhaps we can get to work on the display brightness issue........

[mulletman13]

The thing that bothers me about the powering of nodes messing this up is the short burst of sound when unplugging the AC adapter. Does it switch to some interim power state before moving to OS to the battery? ... sorry that sounded stupid. Hardware-wise I know that it just moves immediately, but I'm curious as to why everything is satisfied momentarily when unplugging.... hrmmm...

Sorry for being here for moral support, but if there is anything tedious/ time consuming you need I'm here 8)

[T u r b o]

The thing that bothers me about the powering of nodes messing this up is the short burst of sound when unplugging the AC adapter. Does it switch to some interim power state before moving to OS to the battery? ... sorry that sounded stupid. Hardware-wise I know that it just moves immediately, but I'm curious as to why everything is satisfied momentarily when unplugging.... hrmmm...

Sorry for being here for moral support, but if there is anything tedious/ time consuming you need I'm here 8)

What kext are you using exactly that works with this short burst of sound? Can you send it to me?

I have a few ideas on what might cause a symptom like that - on my system I haven't gotten a peep out of it yet.

- Turbo

[mulletman13]

I just performed a 100% fresh install and the behaviour is gone now. I know for a fact that Popophobia had the same thing happen to him-- hopefully he could upload his kext files. I believe he said all he did was apply the Azalia patch (which I am unable to find) after a fresh install.

[jacob019]

I don't think the burst of sound means anything. When linux windows or the bios utility are loaded on my X61, the computer will make a sound whenever the ac adapter is unplugged or replugged. I think this sound popophobia is experiencing must be related to this. I don't think the azalia driver works at all with our chip.

EDIT: based on the response below, I am wrong about this.

[mulletman13]

Well I've disabled all beeps and everything regarding power changes and the like. Basically what happened is I'd play a song in iTunes... unplug the AC Adapter, and I'd hear the song playing for a half second or so. Same thing with videos, or anything involving any *actual* sound and not alert messages.

On another note, is anybody having issues with their fans? My laptop seems to be running hot and although I removed the termal kext's in installation, I can't figure out what's up at this point.

[jacob019]

On another note, is anybody having issues with their fans? My laptop seems to be running hot and although I removed the termal kext's in installation, I can't figure out what's up at this point.

we don't have speedstep so the computer will run a bit hot, but it's not too bad. Let's stay on the topic of AD1984 audio in this thread. Perhaps you could restore your computer to the state it was in when you experienced this audio unplug phenomenon, then post your HDA kext.

[mulletman13]

I've been trying various different kext's that I may have installed when I got this thing to happen, but I still am unable to replicate it. Hopefully popophobia can chime in on what he did. I know it seems like I'm making this up-- it was one of the first things I did on my laptop after installing OSX, so it might have been before/during or after installing a bunch of other kext's and such. I'll keep trying to replicate it.

[popophobia]

Hi guys,I can still reproduce the short burst of music when plug/unplug the AC adapter.

Basically Azalia patch moved ALCInject.kext, AppleHDA.kext into AzaliaBackup and create AppleAzaliaAudio.kext in system/library/extensions folder.
I'll try to find the patch again.

But I'm sure it's not the only way to get the short burst of sound. If you check taruga site, seems like there are 2-3 users experienced the same thing without azalia patch. I'll try to install iAtkos 2.0 and see if I can get the same symptom.

Anyway, my system still has the symptom, let me know what kext you would want to look at.

I went ahead and attach the ioreg output and AppleAzaliaAudio.kext. Hopefully it'll have some use.

In ioreg there are a few entries linked back to appleazalia codecs. I'm sure you can get something out of it.

Attached File(s)

 ioreg.txt ( 28.13K ) Number of downloads: 26
 AppleAzaliaAudio.kext.zip ( 73.97K ) Number of downloads: 69