AppleHDA.kext progress

AppleHDA.kext progress

snickersmd 1222911474|%e %b %Y, %H:%M %Z|agohover

Hello all,

I have good news and bad news. Bad news first: Audio still isn't working. Good news is that we are closer. I have played with the kexts until we can now display the same audio devices displayed in Windows Vista, where audio on the 1000H does work flawlessly. Internal Speakers shows up, and switches to Headphones when they are plugged in; and two Microphones are shown in the input device list.

Our hint is that the layout file is incomplete; specifically, it seems to be missing config data on Signal Processing. Without it, the devices load, but curiously, you can't move the volume slider and it says that there are no options for the device. If you copy the Signal Processing data from other layouts, however, the driver no longer loads at all. We may have to get these settings right before we can put this to bed.

I also see that parallel progress is being made using the Azalia kexts. Perhaps the research from either camp can be combined to get working sound with one kext or the other.

Please post significant testing and dev notes in this thread. Refer to the wiki page for a summary of my existing research, and if anything needs clarification, ask here. Thanks!

Re: AppleHDA.kext progress

codeye 1222912909|%e %b %Y, %H:%M %Z|agohover

Snickers,
I haven't played with your modified kext yet but I think the set up that comatron has may be important. I have been able to get sound out fleetingly with the azalia kexts but lose it on sleep or restart, suggesting some sort of race condition. This however does not happen with comatrons set up (my install disk is IAtkos his is ideneb and I suspect there must be difference in the power managment kexts or ?).
This makes it difficult to work out if HDA kext is still faulty or whether its a "powering up" issue on my setup. I will first attempt to get azalia working full time before I play further with HDA because I suspect this may be a critical issue. What do you think?

Re: AppleHDA.kext progress

snickersmd 1222917942|%e %b %Y, %H:%M %Z|agohover

I haven't played at all with the Azalia kext, so I don't know anything about it. Isn't it a third party kext? Is it actively developed? Is it open source? Where can we find documentation on it? Perhaps it is just waiting for the right settings to be plugged in?

Personally, I just want audio working, and I don't care whether it comes from AppleHDA or Azalia. If Azalia is looking more promising, then by all means, work with it. My preference is to continue working with AppleHDA, because determining the right settings would mean that we could simply patch each new version from a pure vanilla install rather than waiting for a third party kext that may or may not cause future conflicts. Power management is also an issue, and working with AppleHDA would probably ensure that sound would move along with any changes to power management kexts as Leopard is updated.

Azalia testing should have a separate thread though. My suggestion would be for the community to play with both until the problem is solved.

Re: AppleHDA.kext progress

comatron 1223022405|%e %b %Y, %H:%M %Z|agohover

aight guys. over on insanelymac forums i am testing 269 kexts done by madtux. he´s the guy with the "manual AppleHDA.kext patching" tutorial which is the ultimative way to get sound (in my opinion). the sad thing is, that progress iss slow. he did about 12-13 versions of the kext and spent a lot of time for this. stickersmd - maybe you should talk to him with your progress and share knowledge - i dont think he will enter here cause he is not eeepc/269 specific.

my progress with azalia is bad too. line out works … BUT … i get 100% cpu when plaaying flashvideos in firefox - it slows everything down. i absolutely dont think that azalia is the way / or should be combined to get this workin. asfar as i know intel dropped that codename "azalia" years ago when the hd-codec thing started. the kext is kinda "universal testing realtek/soundmax/adi etc. output" nothing more. it was dropped to the first release of osx intel (or beta) and just for testing outputs on the "new codecs" in this time. long ago and no development was goin in that direction.

like i said - thats what I know - if it´s not this way, let me know. so stickersmd - can you sent me the testing kext and please contact madtux over there on insanely? would be nice to hear sth. more …

Re: AppleHDA.kext progress

codeye 1223032137|%e %b %Y, %H:%M %Z|agohover

I agree that azalia is not the way to go, but I'm concerned that even if I get the correct info plugged into the AppleHDA.kext that a race-condition may stop it powering up the speakers. This is was I thought I would try at least to get azalia working first as it seems from my reading on insanelymac that most people who get apple HDA working seem to be able to get this working on their machines as well. Which at present I cannot.

Re: AppleHDA.kext progress

snickersmd 1223032935|%e %b %Y, %H:%M %Z|agohover

I have already provided the testing kext on the wiki. It is attached to the page. You should be able to download it using the "files" link at the bottom of the wiki page.

Re: AppleHDA.kext progress

codeye 1223034865|%e %b %Y, %H:%M %Z|agohover

Comatron,
The AppleHDA kexts that you were trialling, presumably 10.5.5 based, did they load at all, were there any errors in dmesg/sys.log?

Last edited on 1223034922|%e %b %Y, %H:%M %Z|agohover By codeye + Show more

Re: AppleHDA.kext progress

AgentMcMillan 1223059352|%e %b %Y, %H:%M %Z|agohover

With the creation of the dell mini 9 they now have a working kext that supports sound. so how close is the eee 1000 to the chip in the mini 9?

Link

Progress Update

snickersmd 1223109469|%e %b %Y, %H:%M %Z|agohover

@AgentMcMillan:
The Dell Mini 9 appears to use ALC268, not ALC269. There is significant difference in the way these chips are recognized and handled, in spite of the fact that the model numbers are only one apart.

I am getting even closer to cracking the way the codec works. Both Microsoft and Apple feed codec information to their respective drivers in the same format, since it is after all standardized. The problem is that Apple stores it differently in the plist. Understanding the right way to give it the data is the key.

For instance, we do have the correct pin config data courtesy of the Windows Vista Registry dumps that people have been making. It *looks* like it is in the same format as the config data in the AppleHDAController plist file, but there is one difference that I have found.

The clues to this is that after plugging in what looks to be the right pin config data, the driver still fails to load with system.log errors of "32 < fNumProcessingCoefficients" failed among others. A decompilation I made of the AppleHDA Driver shows this error message is part of a function called AppleHDAWidget_forNodeID, and the Intel HD Audio Spec does list that every widget has a configuration to describe the processing coefficients. What this all boils down to is that we are feeding the wrong pin config data to the driver, and the config data we pass does not match the pins in the same order that the driver wants.

For instance, the pin data supplied by the Windows Vista reg dumps for ALC269 is in sequential order: 0x11,12,14,15,16,18,19,1a,1b,1d,1e.

The pin data for the ALC885 in the AppleHDAController plist is not in sequential order, however:
0x18,1a,19,15,1f,1e,14,16,17,1b,1c,1d

We need to find out why Apple doesn't put their pin config data in the sequential order, so then we can rearrange the pin config data that we have for the ALC269 in the right order.

One thing I would like to have for comparison would be Windows Vista dumps for actual Mac hardware, so I can compare the formats used by Windows for known plist data. Does anyone here have a working Vista installation on a MacBook Pro or such?

Re: Progress Update

comatron 1223112620|%e %b %Y, %H:%M %Z|agohover

this sounds very logic to me - i hope we will progress that way … heres some dump from a macbook 2007 - dont know i he had xp or vista runnin …

http://pastebin.com/f418cc013

Re: Progress Update

snickersmd 1223117758|%e %b %Y, %H:%M %Z|agohover

@comatron
Thanks for the quick reply. Unfortunately, I don't think this dump was made with Windows Vista. Only dumps made under Windows Vista, using the Microsoft UAA Class Driver will be of any use.

Working more on the problem, I tried removing all pin config data completely to see if the AppleHDA driver could pull the right values by itself, but no dice. Same error messages. So perhaps the pin config data is not behind the problem I'm seeing, but it is still critical.

Also, there are two default pin config sets for ALC885. One does not have the pins in sequence, the other does. Furthermore, the pin configs are different in each set. Two different configs for the same codec chip? This means we need the Vista dump more than ever in order to determine how Apple's plist works.

Breakthrough!

snickersmd 1223125659|%e %b %Y, %H:%M %Z|agohover

Up until this point, no amount of patching or plist manipulation would allow the latest 10.5.5 AppleHDA.kext to load. The prior closest came from a modded kext from codeye (which he in turn had adapted from a Taruga patch). The difference is that the newer kexts have separate internal plugin kexts like the AppleHDAPlatformDriver.

The newer AppleHDA kext has much greater potential to work correctly. The constant evolution of the kexts included under AppleHDA show that Apple's driver is coming closer and closer to being truly universal, like the Microsoft UAA class driver. However, Apple of course has no need to provide universal codec support — only support for codec chips in official Apple hardware — thus they hard code the config data and do not bother to implement the same level of auto configuration found in the Microsoft UAA driver. This is all speculation on my part, but I feel they are relevant and reasonable assumptions.

So what was keeping the latest 10.5.5 kext from loading? It didn't seem to matter that we were patching the codec ID or the plist, it would always crash in the system log with "32 < fNumProcessingCoefficients" failed. The answer was staring us in the face the whole time, with the linux codec dump.

Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono
Processing caps: benign=0, ncoeff=33

The AppleHDA.kext doesn't want to process more than 32 coefficients, but a vendor configuration insists on 33! (Don't know if this is Realtek's or Asus' doing). So I patched the AppleHDA binary to pass on 33 instead of 32, and now the latest 10.5.5 kext is loading with the speakers and proper device listing, but still no sound.

Although there is no sound, now my system.log is full of other less cryptic messages about lacking the proper configuration. So now it's really about tinkering with the plist until this works, hopefully.

I will be setting up a clean kext to work with, so we can try to figure out configuration together.

Re: AppleHDA.kext progress

codeye 1223125965|%e %b %Y, %H:%M %Z|agohover

Hi guys,
Nice debugging! One quick option would be if comatron still has his macbook (and it uses ALC885 l wasn't sure when he provided that dump earlier on insanelymac) is to rearrange the pin configurations to match the vista order and see if that screws up the codec loading in the same way the alc269 is failing.
I have installed ideneb now instead of iatkos that I was using, so i think i'm on the same page as you guys, but are we trying to get the old kext working or moving onto 10.5.5? Oops didn't see the above post! I might have access to a macbook and macbook pro in a week or so - i can install vista at that stage and have a look at the registers.

Last edited on 1223128396|%e %b %Y, %H:%M %Z|agohover By codeye + Show more

Call for testers/devs

snickersmd 1223188225|%e %b %Y, %H:%M %Z|agohover

Here I am posting a 10.5.5 kext testing pack. We need as many people as possible to test different parameters until we find a working pattern. This is a significant landmark, because this kext properly loads the Internal Speakers/Headphones devices, as well recognizing both the Internal and External microphones and distinguishing them apart by proper text labels (Previous kexts listed two Internal microphones instead).

Where we are

This kext file is a direct patch of the 10.5.5 AppleHDA.kext. It has been patched to load ALC269 on the ipis with three binary patches:

Replacing 0x6202ec10 with 0x6902ec10 (x2) and a single byte patch of 0x20 to 0x21.

The AppleHDAController plist file, together with the HDAEnabler.kext, have been changed to load the pin configurations we got from Windows Vista, and points towards using Layout 12, Pathmap 16 in the AppleHDAPlatformDriver plist.

The Pathmap has been arranged in a 1,1,2 setup with Mic, Mic, Group (Int Speakers & Headphones) with the nodes as described in the wiki.

The Layout is pretty much blank. It lists the 4 audio devices, and the input/output groupings, with no other parameters defined. This is where we need help.

Also in the archive: the stock plist from a 10.5.5 AppleHDAPlatformDriver.kext, and alias/shortcuts have been setup to take you straight to the Contents folder and to directly edit the Controller and PlatformDriver plists.

Things you need

The AppleHDA.kext testing pack (zip file)
Property List Editor and/or a good text editor (TextWrangler is a good choice)
kext helper

What to do

First, you need to remove any previous audio testing files that you may have been playing with, including AppleAzaliaAudio.kext, AppleHDA.kext, ALCinject.kext, and HDAEnabler.kext. Note that HDAEnabler is already provided in this AppleHDA.kext bundle, and no longer needs to be a separate kext.

Next install the provided AppleHDA.kext and reboot. You will see the new devices in System Preferences, and you can put the speaker icon in the menu bar.

Pull up the console and filter the messages to see only those that mention HDA. You will see a series of messages from missing configurations. This is where community effort comes into play.

Use the stock PlatformDriver plist as a reference, and copy configuration values from similar items in stock layouts to the items in our layout. I suggest you do this one value at a time, hence the need for a community effort. Copy a value from a stock Mic item into its corresponding position on our kext, and save the file. Install and reboot.

On reboot, open the console again and take notes on how the error messages changed. Note what you changed and the results, then post them here.

Warning: if you make a bad change, your boot will stall at a blue screen. This is because if the change is not correct, the ACPI service can't load the correct device identifier. Do not panic, leave for a while (can take 5 to 10 minutes) and you will be allowed to login. Be sure to take note of the error messages again. Common culprits that I have found are MuteGPIO and SignalProcessing keys. However, we can't avoid those keys, they are the critical ones we need. So what we are doing is both a community brute-force-trial-and-error effort as well as an effort to perhaps intelligently derive the pattern for correct keys. Clues to the correct values can often be found by scanning over the Intel HD Audio Specification; download the pdf from the Intel website.

Reporting back to the forum with your findings is critical

Repeat until a working configuration is found.

Good luck!

Re: Call for testers/devs

YEEEEABOYYEEE 1223200506|%e %b %Y, %H:%M %Z|agohover

I'd love to help, but I can't find that zip-file anywhere?

Re: Call for testers/devs

snickersmd 1223205625|%e %b %Y, %H:%M %Z|agohover

There is a 'files' link at the bottom of every page in this forum and wiki, where attachments are stored.

Re: Call for testers/devs

YEEEEABOYYEEE 1223206746|%e %b %Y, %H:%M %Z|agohover

I can see the files link on wiki pages but not in this forum.

Can you UL it to the wiki page maybe?

Re: Call for testers/devs

comatron 1223210152|%e %b %Y, %H:%M %Z|agohover

same here … just found the one on wiki/internal sound and on bottom "files" but i guess its the "old one" right? please upload :)

Re: Call for testers/devs

strongesthylian 1223246912|%e %b %Y, %H:%M %Z|agohover

I'll begin working on this as soon as you post the file.
Upload the file on the wiki page. :D

Re: Call for testers/devs

nhirt 1223283694|%e %b %Y, %H:%M %Z|agohover

Hi,

You did indeed upload the file "hdatestpack.zip" (see here: http://www.wikidot.com/user:info/snickersmd under recent conrtibutions).
But somehow it is not attached to any tread.
Please post it again (as fast as possible) so that we can start testing…

Thanks,

Nik

Re: Call for testers/devs

comatron 1223297086|%e %b %Y, %H:%M %Z|agohover

true. cant access the file that way … please provided asap for you so we can start the hunt …

Re: Call for testers/devs

Diamondsw 1223312599|%e %b %Y, %H:%M %Z|agohover

Like most (all?) others, there's no "files" link on this page. Safari on OS X 10.5.5 - about as vanilla as you can get.

Re: Call for testers/devs

elroy 1223392415|%e %b %Y, %H:%M %Z|agohover

Use the stock PlatformDriver plist as a reference, and copy configuration values from similar items in stock layouts to the items in our layout. I suggest you do this one value at a time, hence the need for a community effort. Copy a value from a stock Mic item into its corresponding position on our kext, and save the file. Install and reboot.

I'm sorry, but I don't follow this part: "copy configuration values from similar items in stock layouts to the items in our layout" - copy from where… to where? Am I suppose to install the PlatformDriver.plist into my preferences folder? Or are we just suppose to use its layout as a guide?

Also, I've installed the AppleHDA.kext bundle and I can't add the sound icon to my menu bar - nor are there any sound devices detected.

Sorry if I'm being thick.

Re: AppleHDA.kext progress

snickersmd 1223315721|%e %b %Y, %H:%M %Z|agohover

Hmmm… I didn't know you guys couldn't see a files link. It may just be an admin feature then. Sorry about that.

Try this link:
hdatestpack.zip

Re: AppleHDA.kext progress

nhirt 1223362717|%e %b %Y, %H:%M %Z|agohover

Yes that did it.
Downloading now, thanks.

Nik

Re: AppleHDA.kext progress

akrylic 1223315902|%e %b %Y, %H:%M %Z|agohover

So am i, i can't access to files. I haven't an eeepc but an lenovo s10, it's the same card, alc269 :)

(Sry for my english, i am french)

Re: AppleHDA.kext progress

comatron 1223390527|%e %b %Y, %H:%M %Z|agohover

maybe this worx for you to download akrylic:

http://ipis-osx.wikidot.com/local--files/forum:thread/hdatestpack.zip

AppleHDA Newbie Notes

snickersmd 1223415011|%e %b %Y, %H:%M %Z|agohover

@elroy
No problem. I'm afraid I wrote the intro with the assumption that community members willing to tinker with this already had a working understanding of how the AppleHDA.kext is configured.

The AppleHDA.kext has several nested kext plugin components and each carries some part of the configuration. The correct configuration consists of a working pin configuration, pathmap and layout. The pathmap has been figured out already (presumably), and so have the pin configurations and basic layout, so you shouldn't need to touch these unless you find some reason that they should be modified as well. The pin configurations are loaded from AppleHDAController's plist, and the layout and pathmap are loaded from AppleHDAPlatformDriver's plist.

Under each audio device in the layout, there are specific configuration parameters that must be filled out. We don't have this information yet, so we start by testing different values we already have in Apple's stock configuration. If you open the stock plist, you will find some 20 or so different layouts each with different devices and their respective configuration values. Your job as a tester would be to copy values from this file into our layout file and note the effect. So, yes, the stock configuration is offered as a reference. If all you had to do was copy the whole thing, then there would be no need to distribute the files separately.

Also note that Apple's stock configuration supports a number of different codec chipsets, but since we will likely get the best results from settings for another Realtek codec, then it is reasonable to test only those default values taken from layouts intended for Realtek codecs. These can be identified by the codec ID field in each layout.

***

If you aren't getting sound devices, then the kext hasn't been installed properly. Did you use kext helper to install? Did you have any prior instance of sound driver attempts installed? Did you try flushing (deleting) your extensions cache, to make sure you were loading the new kext instead of a stock AppleHDA.kext? What does your console/system log say?

Last edited on 1223415148|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA Newbie Notes

baza210 1223422451|%e %b %Y, %H:%M %Z|agohover

Hi

I'm running Ubuntu on an Eee 1000H, and if there's anything [simple] that I can do to help, I'd like to. Mainly because I'm sick of my Linux/XP dualboot and miss my old iMac. Sound works perfectly in Ubuntu.

Re: AppleHDA Newbie Notes

strongesthylian 1223431992|%e %b %Y, %H:%M %Z|agohover

I believe by Extensions Cache, you mean to delete /System/Library/Extensions.mkext, correct?

Re: AppleHDA Newbie Notes

snickersmd 1223439140|%e %b %Y, %H:%M %Z|agohover

That would be it… Sometimes just to be safe I delete all the cache files.

sudo rm /System/Library/Extensions.mkext*

Re: AppleHDA Newbie Notes

luthian 1223481485|%e %b %Y, %H:%M %Z|agohover

I'm not sure if it is helpful but since Ubuntu supports this chipset natively, might someone be able to pull the right values out of the Ubuntu sources? A quick Googling brought up this diff for adding support to Ubuntu for the ALC269 in the EEE PC 901: Diff file

Re: AppleHDA Newbie Notes

comatron 1223484416|%e %b %Y, %H:%M %Z|agohover

^^ stickersmd - does luthian´s intension go into the right direction? im still hunting for someone with a macbook/pro running vista and giving me his regkeys - this mission seems to be impossible - never thought that …

Re: AppleHDA.kext progress

snickersmd 1223517878|%e %b %Y, %H:%M %Z|agohover

@luthian & comatron
No, I recommend to stop looking for regkeys and support from other operating systems for now. The data from there has already been put into the kext. The trial-and-error process is specific to the Apple platform. The thing is, in both Windows Vista's UAA Class Driver, as well as the Linux ALSA modules, the drivers are setup to autoconfigure based on detection, since they are meant to be universal drivers. Remember that Apple only writes drivers for hardware that they themselves use, so they didn't bother with autoconfiguration. Why should they? They know exactly what chips they use and just hardcode the configuration data for just those chips. It makes it easier for them to support. It's one reason Apple systems are robust and trouble-free, because they don't have to worry about supporting all hardware, just the hardware that they make. The HDA specification itself is universal, and the fact that the AppleHDA.kext can be hacked shows that it can be adapted for chips other than those used in Apple hardware. It is simply up to us to find the right Apple-style configuration.

It is just our luck that the ALC269 is significantly different from other ALC chips, such that simple drop in hacks don't work. We need specific config data. As I have said before, it will either be found by trial-and-error, or by seriously studying the Intel HD Audio specification and finding out what exactly the numbers in the stock configuration represent, so that we can find the correct numbers for the ALC269.

Has anyone here actually started doing the trial and error process?

Re: AppleHDA.kext progress

comatron 1223530319|%e %b %Y, %H:%M %Z|agohover

me not :( i´m too noobish - event tho i got a damn great motivation …

Re: AppleHDA.kext progress

Toonces 1223592556|%e %b %Y, %H:%M %Z|agohover

Hi, I just got my 1000H today but have been following your progress for the last week in anticipation. One thing I notice when looking at the linux source is that the 901 is handled differently from the auto and basic ALC269 driver. The 901 is an 8.9" version of the 1000 series and uses an Atom processor instead of the Celeron. From the hardware specs at asus, it's identical to the 1000HA except for the screen size (No BT and 802.11G only). That makes me think that perhaps the ALC269 in our 1000H probably needs those same differences and why it may not be working with the stock configuration of the apple drivers. I am attempting to read through and figure out what the actual differences in the linux driver are but I'm no programmer so it's slow going. Anyways, I think the differences in the linux driver may be of significance to us if we can figure out what the specific differences are.

I am still waiting for my USB slot load DVD-RW drive to get here so I can join in on the fun and testing!

Re: AppleHDA.kext progress

Toonces 1223593155|%e %b %Y, %H:%M %Z|agohover

Actually, I just confirmed it. The 901/1000/100H have some peculiarities that required patches to the stock ALSA drivers specifically for these eee models. See http://forum.eeeuser.com/viewtopic.php?id=38030&p=1

Re: AppleHDA.kext progress

snickersmd 1223602547|%e %b %Y, %H:%M %Z|agohover

Everyone: I realize that everyone is doing their best to help out by looking for solutions elsewhere, but I'm really waiting on those trial-and-error results. I'd do it myself but it would simply take forever having to wait and reboot for each entry, hence I brought it forward for the community to help out on. Figuring out how Apple encodes their configuration is the key. Yes, I am fully aware that ALSA required special patching for the driver to work on the ipis, but it doesn't really help us on OSX because we don't have driver source code to patch. We can only change configuration. Changing configuration is all the Taruga patcher does to get sound working on other models, so it is the only way. Vista and Linux can only give us hints, but please start experimenting with the configuration presented in AppleHDAPlatformDriver plist.

Not trying to be an ass and shoot other community members down, it is just frustrating to check the thread daily only to see people are posting things they researched that have already been researched — we are moving in circles. (The wiki details how I already loaded the latest correctly patched ALSA with ALC269 support and used it to generate a codec map with the complete configuration data as Linux uses it) Somebody please try my approach with the plist unless a better one can be suggested. (Because frankly, I'm not excited about trial-and-error substitution, reboot, test and log and repeat myself)

@comatron: Do you still have your working Azalia setup with headphone out only? Unfortunately, the Azalia kext does not seem to have any configuration in the plists, but it just occurred to me that the configuration from there may be loaded by the driver directly into the IO registry. Please obtain IORegistryExplorer and dump the whole AZAL or HDEF tree.

@Toonces: Welcome, I'm looking forward to you getting your drive and jumping right in. If you have Linux with working sound, you could generate a codec dump and map and see if it's any different or tells us anything different than the work I have already done with ALSA 1.0.18rc3.

Re: AppleHDA.kext progress

elroy 1223608986|%e %b %Y, %H:%M %Z|agohover

Not to be an ass either snickersmd, but there's little point in complaining about people not helping when you've not made it easy for *noobs* to get on board and help.

I'm currently recovering from operations on both of my eyes, but was able to do enough research and trial and error to get most things running on my new eeepc (admittedly most of my problems initially were the result of me trying to get OS X running on the 1000HD without patched bios)… but I digress. My point is that even under these conditions I was able to work a lot of stuff out and follow the instructions on how to set up an EFI partition and boot from a vanilla install of leopard… but I can't make heads nor tails of the *instructions* that you've posted above.

I really want to help, and perhaps I'm just a moron… or perhaps I'm the only one prepared to point out that I don't really understand what you're asking people to do… but maybe you could write a detailed tutorial on what people need to do (please include ALL file locations and names).

I understand that you're frustrated by the lack of help. But by spelling out to people what it is that you need done will surely help get people on board.

I don't want to waste your or my time, but if I can't be sure that I'm doing exactly what you're asking for, then that's exactly what I'd be doing.

Re: AppleHDA.kext progress

Toonces 1223617557|%e %b %Y, %H:%M %Z|agohover

Hi snickersmd, I am looking forward to being able to try to assist with solving the problem. My reasoning for looking into the linux source changes are exactly because we don't have source to work with. I can only assume that what we have to work with using Apple's drivers is the equivalent of ALC269_Basic. Now if the changes to make sound work on the 901/1000/1000H are significant enough that the sound did not work with the ALC269_Basic driver in linux, I don't see how any amount of remapping pins is going to help. Unless of course, that is what the changes to the ALSA source do. If that is the case, then the answer to what configuration is correct should also lie within those changes. Unfortunately, at this point, all I have on my 12 hour old 1000H is XP. I received everything I ordered last week except my DVD drive. The seller I bought it from sent it and it seems like it's being carried by bicycle from Northern California to me here in Southern Arizona. I hope I get it tomorrow or maybe Saturday at the latest so I can spend some time over the weekend getting ready to test. Until then, I have written the author of the linux patches to see if he can shed some light on the subject. Hopefully he is willing.

Re: AppleHDA.kext progress

snickersmd 1223621907|%e %b %Y, %H:%M %Z|agohover

@Elroy
Fair enough. I started these forums so that we could work together. Granted, not everything is going to be clear, but yours is the first post actually asking for clarification — I do want to build a "newbie" friendly environment but I also want people to ask informed questions by reading what's on this thread, other threads, the wiki, other forums. That's why I left maceee.com, since people would ask the same questions over and over without carefully reading the previous posts.

If you can't make "heads or tails" of the instructions, I don't think it's moronic — this sh*t is confusing for anyone, myself included and I'm facilitating — but have you tried opening one of the plists in Property List Editor? Do you have the Property List Editor already? If you're interested in helping but don't know where to start, I need to know where you're stuck. I think that if you open the plists in Property List Editor, the instructions on what to do become rather evident, but if the majority of the people passing through this thread don't know what a plist is or where to find it, then forgive me for not starting at the *very* beginning — it's been a long journey getting to this point with the pure lack of documentation that there is.

As much as I would like to write a detailed tutorial with screenshots, I simply don't have the time. But I can walk you through if you ask the right questions. Where are you in the process? Have you opened the plist and don't know how to edit it, or are you at the point where I have to explain what makes up a kext? Before I sit and make a post, please ask me specific questions and I'll be happy to help you out.

Sorry to hear about your surgery, I hope your recovery is swift and uncomplicated. I myself am preparing for upcoming medical board exams, which is the primary reason I can't be glued to the computer screwing around.

@Toonces
Actually, AppleHDA.kext isn't even at the level of ALC269 basic. The entire point of the Intel HDA specification is to facilitate a system where only one driver works for all implementations. Microsoft's UAA Driver is the template and of course works flawlessly. It's not a question of specifically supporting each chip through driver code, but rather, to derive configuration data to let the universal driver hook into the codec chip.

Remapping pins should no longer be the issue. That has been solved, and is already included in the testing kext. If the pins and maps were not correct, then the devices would not load at all. What we need is further configurations, let's call them layout settings, and this is different from the pin configurations that everyone has been looking at.

Let me see if I can simplify this, since it took me a while to figure this out, and heaven forbid you should have to endure reading the whole Intel HD Audio spec plus the Microsoft UAA Pin configuration docs (but you ultimately may need to in order to help :()

Intel made HDA such that any manufacturer could design a codec chip that would simply plug into its chipset, which in turn provides a standard interface for a universal driver to access the sound system without having to program a separate driver for each kind of codec chip.

The codecs are comprised of pins or widgets. A widget or group of widgets make up a node, and several nodes are grouped together to form a function group. A function group can be an audio device on its own, or can be grouped together with other function groups to make a device complex.

As far as I have found, each pin has a register with default configuration. We also need the node addresses for each pin so that we can group the right pins together. After that, each device has its own settings in order to work. When a universal driver like the Microsoft UAA Class Driver in Vista plugs in, it queries the codec chip and gets the configuration automatically and loads it. Since everything is perfect there, all chips automatically work in Vista. In ALSA, they don't have the luxury of actually knowing the exact way that Microsoft's driver pulls this data out, so their driver is less than perfect. Still, when it works, it knows to pull this configuration out and use it.

Apple's driver is different. It doesn't autoconfigure in the same way. The configuration data is written in xml-based property lists by Apple, who know all the parameters that are needed. If we supply it other correct configuration data, Apple's driver works fine, which is what people have been doing all this time with the Taruga patcher. But Apple's driver won't ask for the configuration the way that the UAA Class Driver or ALSA will. Therefore, knowing how ALSA works may not really help us.

Apple stores the configuration in plist files inside the kext bundle. These are plain-text xml based files that store the correct values of nodes and pin configurations and audio function groups. A Pathmap tells what nodes make up what groups and how they are arranged. This is where you say, I have an audio input device with nodes x, y, and z, meaning that audio comes in and passes through nodes x, y, and z; or a compound audio output device with nodes a, b, and c leading to internal speakers; and nodes d, e, and f leading to the headphone jack. The Taruga Patcher takes the node structure from an ALSA Linux codec dump, and then plugs the data into the correct format in the plist. In the case of the ipis, this has been done already, the pathmap is complete.

Another place where Apple stores configuration is in the plist of the AppleHDAController, where it stores default pin configuration registers. The same data is present in the Vista registry dumps and the Linux codec dumps. In our case, this has also been taken care of.

Both the Pathmap and the Default Config point to the Layout. The Layout is just a listing of the audio devices present for a given audio codec. For the ipis, we have Internal Speakers, Headphones, Internal Microphone, and External Microphone. Under each device, there are special settings which configure other properties they need to work, like the MuteGPIO and Signal Processing settings. This is what you need to look at changing I don't know much about what those settings are, but it is my hope that by plugging stuff in trial and error, we can find out what works and what doesn't.

So look at a stock Apple configuration and find the Layout section, you will see these lists of audio devices and each one will have some settings there. Then look at our Layout section and see that there are none. Try putting settings from the stock config in the testing config and see what happens. That's it.

Re: AppleHDA.kext progress

MacLovin 1223639420|%e %b %Y, %H:%M %Z|agohover

@snickersmd

I understand your frustration and I'm hearing you out. You've done a great job with what you've done so far. I feel like I can be a big help. I've created successfully working ATi drivers for non-supported cards, modified bios's, and have been working somewhat with AppleHDA to get familiar with it. Even though my 1000H is on the truck for delivery, I just want to chime in and let you know that I will be looking forward in helping you complete your fantastic project. Last thing I want you to do is give up on the community and abandon it, so hang in there, once I get the 1000H in my possession (October 13th ::crossing fingers::) I will try to make headway with what you've done. Again, keep up the great work!

Re: AppleHDA.kext progress

Gregory Cohen 1223641773|%e %b %Y, %H:%M %Z|agohover

I'll help too, once I get my desktop back to life. At the moment the eee is my only working box.

-GReg

Re: AppleHDA.kext progress

Toonces 1223663884|%e %b %Y, %H:%M %Z|agohover

snickersmd, Thank You for the further explanation. I spent a couple of hours going over the various threads on patching AppleHDA and going over the linux patch source. One thing I noted is that the ALC269 shares a lot of the same outputs with the ALC880. It looks like in some parts of the linux source that where the outputs are defined, they alias them to the ALC880 definitions. Where it's really different is the mic inputs and the headphone out jack. That seems to be what the 901/1000 specific patches address. Our 1000H's have 2 built in mics and the 901 patches fix it so they both work.

I also looked at the stock 10.5.5 AppleHDA kext and the modified layout and pathmap files provided by MadTux. First, the stock AppleHDA kext does not appear to have all of the codecs listed in the codecs.rtf doc provided by MadTux. I searched through the entire layout and couldn't find where the ALC262 was defined at all. Only the ALC885 and Stac9220 seems to be defined in the stock plist files. I am of course, assuming the file MadTux identifies as an unmodified AppleHDA 10.5.5 kext is indeed, unmodified. Next I took a look at the modified layout and pathmap files he provided as a guide and compared them to the unmodified. He deleted all but 1 layout which when looking at it, may be a mistake since the layouts vary so much. Specifically, The DSP settings were very different from the modified to stock version. It seems to me that these definitions are most likely pretty darn important to get right and that his layout may not be the best one to use at this point. Of course I could be completely wrong and his might be the correct one to start with. Anyways, I am starting to sort things out enough that I think there may be an easy way to find out some things to get basic sound going and go from there until we have it all.

Here's what I am thinking. I can't test this out but perhaps you can. Since the ALC269 & ALC880 seem to share common outputs, If we start with an already known good working ALC880 patched AppleHDA kext like the one MadTux provides as the end result of his tutorial http://forum.insanelymac.com/index.php?act=attach&type=post&id=34431 and modified it with just the ALC269 edits to the CodecID that we should get audio out without having to change anything else. The mic & headphone jacks are sure not to work but I think speakers should. Unfortunately this is something I cannot yet test but should be a quick edit and check for you. If the audio out does work then we know that the particular layout (including the DSP definitions) and pathmap for the working functions would be correct and we can go from there to fix the ones that are not correct. If it doesn't work, the next thing to check would be the pin mappings to make sure they match what we have for the ALC269. If it's just the pin mappings that are wrong, I would think the DSP related stuff would at least be correct. Again, I may be way off in my understanding of what I am looking at but it seems to me that it may be the easiest path to working audio. Trying to figure out which layout is the correct one to start off with in the 30 layouts in the stock AppleHDA seems like a much longer and more tedious task, though that may very well be what we have to do.

Let me know what you think and if you can, please try the simple test of modifying the already working AppleHDA kext for the ALC880 and see what you get. Hopefully I will be able to join in on the fun with some real testing this weekend.

Re: AppleHDA.kext progress

snickersmd 1223675767|%e %b %Y, %H:%M %Z|agohover

@Toonces,

I've actually been through several "known working" ALC880 kexts and that is what brought the current kext to where it is now. As a matter of fact, codeye's earlier work was based on working ALC880 kexts, and I picked up where he left off by modifying his work and putting it onto a patched 10.5.5 kext. I don't think the ALC269 can be compared to the ALC880 because the ALC269 is a 2 channel codec and the ALC880 is a 6 channel codec.

The testing kext that I released has what I believe to be the correct layout, pathmap, and pin mappings. This is supported by all the evidence in the ALC269 datasheet, Linux codec dumps, maps, and Vista registry dumps. If it didn't, then the audio devices would not load at all. I didn't take the layout from a stock layout, I custom built it based on how Windows Vista sees the devices.

At this point, I don't think substituting whole layouts from the stock config are going to do anything because they simply do not match up with what is in the ipis. I assume my layout is correct because it loads, but it does not process sound because of lack of DSP settings. The whole trial-and-error push is to get us the right DSP settings, and nothing else. My contention is that since the ALC269 is different, we need special DSP settings. As you put it, you assume that the pin mappings are wrong and the DSP settings are correct. My findings are that we already have the right pin mappings, and it is the DSP settings that need fixing. So far, we are in uncharted waters, because no one else has had to change DSP settings, just us lucky folks with an ALC269.

The MadTux tutorial is simply a manual reverse engineering and explanation of what the Taruga Patcher automates. Getting the AppleHDA kext to work for the ALC880 when it originally supported the ALC885 is a matter of changing the pin mappings, pathmap and layout, but the DSP settings stored in the layout are never touched. They seem to carry over just fine from the ALC885 to the ALC880.

On the other hand, I tried moving DSP settings from the ALC880/ALC885 into the layout I made for the ALC269 and it simply failed to load. That is the reason that I believe the problem has to do with the DSP settings, but I don't know which one. They have to be tested one by one until we find out which ones work and which ones don't, then we can look at the ones that don't and see what needs to be changed.

Last edited on 1223778937|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

Toonces 1223687050|%e %b %Y, %H:%M %Z|agohover

Thanks for the explanations regarding what you've done so far in answer to my research. It looks as though we're drawing a lot of the same conclusions and at least on the same track. My drive still hasn't shown up so it's going to be another night of reading and just working through it in my head. One thing, are the DSP definitions in your testing codec the same as they would be for the same function on another HDA chip? This was the biggest difference I noticed in MadTux's modified plists vs. the stock ones. here's what I mean, in the stock info.plist, layout item 1, signal processing, softwaredsp, dspfunction0, function info, the first dspfuncname is DspGainStage. In MadTux's modified platform.plis, the same DspFuncName is DspNoiseReduction. So which is the correct one? With the ALC269, what functions should we expect to see? I don't think you know either but that is where all the different layouts come into play. They all have different functions associated with the particular pieces and I guess we need to figure out which ones the chip is expecting to use and in which order. I am sure you have the pins, etc mapped out but the dsp functions associated with those mappings are the next step. Yes, I realize that is what you've been saying but I had to catch up to be of any use :D

Re: AppleHDA.kext progress

strongesthylian 1223677665|%e %b %Y, %H:%M %Z|agohover

Like elroy, the sound devices don't install when I install the HDA kext. I've taken out any related Audio Kexts, fixed the permissions, flushed the Extensions cache, and even touched the extension folder.

One thing worth noting is that the audio devices are recognized in System Profiler, but the devices aren't there in the Sound preferences.

Rather than fill the screen with my screenshot, here's a link to it:
http://img381.imageshack.us/img381/8472/audioup3.png

Re: AppleHDA.kext progress

snickersmd 1223678240|%e %b %Y, %H:%M %Z|agohover

That's really odd. I have the same system profiler report, but the devices show up in my sound preferences as well.

What does your system log say? What about the IORegistry?

Re: AppleHDA.kext progress

strongesthylian 1223679433|%e %b %Y, %H:%M %Z|agohover

Sorry not very savvy on checking the logs. I open up the Console and search HDA and find:

Oct 10 15:06:07 localhost kernel[0]: HDAEnabler: Copyright (c) 2008 by Kabyl
Oct 10 15:06:07 localhost kernel[0]: HDAEnabler: 05/05/2008 Added SPAudio support:Taruga

Re: AppleHDA.kext progress

Toonces 1223713229|%e %b %Y, %H:%M %Z|agohover

Ok, My head hurts from going through this stuff so I posted a thread over at insanelymac for some help. http://forum.insanelymac.com/index.php?showtopic=130616 maybe a little incentive will help move things on.

Re: AppleHDA.kext progress

snickersmd 1223715335|%e %b %Y, %H:%M %Z|agohover

Hahahaha you've just had a taste of the headache I got from learning AppleHDA hacking, I feel your pain. ;)

Re: AppleHDA.kext progress

strongesthylian 1223756005|%e %b %Y, %H:%M %Z|agohover

I tried uninstalling and reinstalling the AppleHDA.kext file. The sound devices weren't there, but this time I got some more console information:

Oct 11 13:06:46 RondeeeMac kernel[0]: HDAEnabler: Copyright (c) 2008 by Kabyl
Oct 11 13:06:46 RondeeeMac kernel[0]: HDAEnabler: 05/05/2008 Added SPAudio support:Taruga
Oct 11 13:06:46 RondeeeMac kernel[0]: Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit
Oct 11 13:06:46 RondeeeMac kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAPath.cpp" at line 1168 goto Exit
Oct 11 13:06:46 RondeeeMac kernel[0]: Sound assertion "0 != pathSet->getWidgetAmplifierGainRange ( &zeroValue, &minValue, &maxValue, &minDB, &maxDB, kPATH_CONTROL_SPATIAL_CHANNELID_Master )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 248 goto handler
Oct 11 13:06:46 RondeeeMac kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAPath.cpp" at line 1168 goto Exit
Oct 11 13:06:46 RondeeeMac kernel[0]: Sound assertion "0 != pathSet->getWidgetAmplifierGainRange ( &zeroValue, &minValue, &maxValue, &minDB, &maxDB, kPATH_CONTROL_SPATIAL_CHANNELID_Master )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 248 goto handler
Oct 11 13:06:46 RondeeeMac kernel[0]: Sound assertion "false == pathSet->isAmplifierGainAdjustable ( kPATH_CONTROL_SPATIAL_CHANNELID_Master )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 3572 goto Exit
Oct 11 13:06:46 RondeeeMac kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 3527 goto Exit
Oct 11 13:06:46 RondeeeMac kernel[0]: Sound assertion "0 != widget->setUnsolicited ( true )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDACodecGeneric.cpp" at line 830 goto handler
Oct 11 13:06:46 RondeeeMac kernel[0]: Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit
Oct 11 13:06:46 RondeeeMac kernel[0]: Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit
Oct 11 13:06:46 RondeeeMac kernel[0]: Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit
Oct 11 13:06:48 RondeeeMac kernel[0]: Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit
Oct 11 13:07:46 localhost kernel[0]: HDAEnabler: Copyright (c) 2008 by Kabyl
Oct 11 13:07:46 localhost kernel[0]: HDAEnabler: 05/05/2008 Added SPAudio support:Taruga

Re: AppleHDA.kext progress

snickersmd 1223778886|%e %b %Y, %H:%M %Z|agohover

@strongesthylian
That's some progress. I found it curious that you didn't have those log errors before. Right now, those are the exact same log errors I get, but the devices do show up on my side. The log errors start to change once I start mucking around with different DSP settings.

Is it just you and elroy that don't have the devices present on installing this kext, or is this everyone who installs the new kext? I wish I knew what the difference in the configuration was.

Re: AppleHDA.kext progress

strongesthylian 1223781958|%e %b %Y, %H:%M %Z|agohover

Might be a good idea to note that I'm on an ASUS EEE PC 1000H 160GB version. Running iDeneb v1.3 OS X 10.5.5. I also installed the kext from a clean install.

Re: AppleHDA.kext progress

elroy 1223785116|%e %b %Y, %H:%M %Z|agohover

I've tried a number of times now to install this kext, but I get nothing - no errors, no devices.

I'm running a clean leopard install with a generic efi boot partition (with all maceee kext's installed except the audio related ones listed in an earlier post).

Re: AppleHDA.kext progress

snickersmd 1223796039|%e %b %Y, %H:%M %Z|agohover

@elroy:
That explains a lot… you wouldn't happen to be trying to install the AppleHDA.kext from your EFI partition, would you? I read from the InsanelyMac forum that audio kexts would still have to be loaded from /System/Library/Extensions, not from the EFI partition.

Re: AppleHDA.kext progress

elroy 1223805765|%e %b %Y, %H:%M %Z|agohover

No mate… for one, installing it onto the EFI is more work than just moving it into the extensions folder using the helper. I wasn't aware that there were issues with installing audio kexts on the efi though, thanks for the heads up. Personally, I'm using the efi as a safety net really, meaning that I can feel safe in running official updates and the worst that will happen is that I have to reinstall a few kexts, not a big deal at all.

Re: AppleHDA.kext progress

codeye 1223825132|%e %b %Y, %H:%M %Z|agohover

Snickers,
Have a read of this http://forum.insanelymac.com/index.php?showtopic=127819
It suggests the config verb order and other useful bits.

Last edited on 1223828387|%e %b %Y, %H:%M %Z|agohover By codeye + Show more

Re: AppleHDA.kext progress

Toonces 1223839703|%e %b %Y, %H:%M %Z|agohover

Hi, I finally got my drive and installed ideneb 1.3 following the maceee guide and installed most of the needed kexts with the exception of using AppleSMBIOSEFI instead of the hacked AppleSMBIOS kext. I also grabbed the 10.5.5 GMA950 kexts which supposedly do not need natit for external display. After I got everything configured to my liking I turned to sound and like strongesthylian, I didn't get any errors on first install. I removed and reinstalled the testing kext again and am now at the same place. I get the same errors :) I also have no devices listed in the sound preferences though I can check the box to show volume in the menu bar and checking it causes a space to be inserted in the menu bar where the sound control should be but no icon or control.

snickersmd, do you have the kext that had all the devices show up but no sound? From looking at the realtek docs, the only major difference with the ALC269 vs a chip like the ALC268 is that the 269 is the only one with a built in amp. I wonder if it's the lack of control for the built in amp that is making that kext not work. i.e. the devices are correctly defined but basically muted because there are no definitions to turn on the built in amp? Didn't you say you had external via the HP jack?

Anyways, I can now do some testing and will keep messing with this testing codec and other definitions and see if I can get anywhere. Do you think maybe it would be best to follow a single line from start to finish? Say take just trying to get the speakers working. You have the pin definitions and can follow that line from start to finish or am I heading off in the wrong direction?

Re: AppleHDA.kext progress

Toonces 1223840012|%e %b %Y, %H:%M %Z|agohover

BTW, here are the errors I get:

10/12/08 1:35:44 AM kernel HDAEnabler: Copyright (c) 2008 by Kabyl 
10/12/08 1:35:44 AM kernel HDAEnabler: 05/05/2008 Added SPAudio support:Taruga 
10/12/08 1:35:45 AM kernel Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAPath.cpp" at line 1168 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 != pathSet->getWidgetAmplifierGainRange ( &zeroValue, &minValue, &maxValue, &minDB, &maxDB, kPATH_CONTROL_SPATIAL_CHANNELID_Master )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 248 goto handler 
10/12/08 1:35:45 AM kernel Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAPath.cpp" at line 1168 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 != pathSet->getWidgetAmplifierGainRange ( &zeroValue, &minValue, &maxValue, &minDB, &maxDB, kPATH_CONTROL_SPATIAL_CHANNELID_Master )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 248 goto handler 
10/12/08 1:35:45 AM kernel Sound assertion "false == pathSet->isAmplifierGainAdjustable ( kPATH_CONTROL_SPATIAL_CHANNELID_Master )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 3572 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 3527 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 != widget->setUnsolicited ( true )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDACodecGeneric.cpp" at line 830 goto handler 
10/12/08 1:35:45 AM kernel Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit 
10/12/08 1:35:45 AM kernel Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit

Re: AppleHDA.kext progress

snickersmd 1223844982|%e %b %Y, %H:%M %Z|agohover

@codeye: excellent find. I thought I had covered all the bases, but someone finally wrote a guide that goes beyond the original Taruga patch. I will read through and try to see if their process alone doesn't get us a better kext. May I advise you do the same using the codec dump and graph provided in the wiki.

@Toonces: It wasn't me with external out, it was comatron using the older AppleAzalia kext. You're on the right track, sans the display of devices. I'm still at a loss to describe why I have the audio devices showing up while now you, strongesthylian, and elroy don't. You can see from the error log why I believe it has a lot to do with the DSP settings and amp control, aren't the error messages highly suggestive?

One thing that's odd: You have the fcontrolarray message 5 times but I only have it 4 times per boot. I had always assumed that this corresponded with a missing control array (DSP settings) per each of the 4 audio devices/function groups that were there. I believe our problem areas are the speakers and internal mic, and I think that's where the DSP needs to be fixed first and what is causing the majority of the error messages.

Keep hacking at it. I will be reviewing this new guide that was published and see if it has anything that I haven't already done.

Re: AppleHDA.kext progress

joeblough 1223852161|%e %b %Y, %H:%M %Z|agohover

this might be a dumb question because i know very little about these kinds of chips. would it make sense to try to do a full PCI config space dump of this chip when running under windows or linux and compare that to what we have on osx after the kext is loaded? or is it the case that you already know exactly what every single register should be programmed to and its a question of trying to coax the kext into doing this for us?

Re: AppleHDA.kext progress

snickersmd 1223852665|%e %b %Y, %H:%M %Z|agohover

It's not a dumb question, but unfortunately the answer is no, it won't work. This is primarily due to the the unique driver architecture in MacOS X. I have read in many places how it is definitely superior to many driver interfaces there are, but it is significantly different enough that we cannot even take plain BSD drivers and hack them into the kernel. (That would have fixed our Ethernet problem right away). All the drivers go through Apple's IOKit framework, so looking at how other operating system's drivers work is of limited value.

That having been said, we do assume that the AppleHDA kext already does what drivers on the other platforms do. Otherwise, why would they use the same nodes and pin config verbs as found in Linux and Win Vista? So yes, you are correct in saying that it is merely a question of "coaxing" the AppleHDA.kext to work.

Re: AppleHDA.kext progress

joeblough 1223856591|%e %b %Y, %H:%M %Z|agohover

well but what i mean is that if you had the full register dump from a working chip, and one from the current state of the art kext, you should then be able to see what registers differ and how, and what needs to happen to make it work. i'm not talking about trying to copy driver source code from linux but just to see exactly what the state of the chip is when its working properly. i guess if you have the linux source then you can tell what registers its writing anyway and to what value, but its a heck of a lot more direct to just look at the dump and see what differs. of course you'll see all kinds of differences depending on what outputs/inputs happen to be enabled but by dumping a few times on windows/linux after twiddling knobs you can isolate those differences.

having said all that, i guess that you do have the datasheet for the part, so in theory you should already know exactly how this thing should be programmed, right?

Re: AppleHDA.kext progress

snickersmd 1223858353|%e %b %Y, %H:%M %Z|agohover

I get what you're trying to say, but it really isn't that simple either. The registers have already been determined, as well as what gets put into them. But we aren't dealing directly with the codec chip itself — from what I understand, we go through a standard interface through the Intel chipset to get audio. It's also too low level, the Intel HD Audio Specification tells us that the codecs are controlled by verbs, not by directly working with registers. Seeing the result will not likely tell us what verbs to use, at least not readily.

So we're not trying to determine a particular state that the chip needs to be in. We had to first determine the proper connections (which we now have), and then the commands that must be sent (i.e. our DSP settings and others). This is crudely analagous to hooking up a monitor to a computer. We are sure the video card is working, and we are sure the monitor is working, but is our cable any good, and are the drivers sending the correct signals down the line? Only in this case, we are dealing with a digital "cable" and a bunch of initialization settings that have to be hashed out.

There is one solution I have considered; the Microsoft UAA configuration documentations state that the driver can be queried through a standard API to determine the correct configuration of the chip. I'm a little rusty with my C++ but I can probably hack a program together that will call that API. However, I don't really have time to do this, and if anybody out there feels like writing such a program I will do what I can to help.

Last edited on 1223858559|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

joeblough 1223860282|%e %b %Y, %H:%M %Z|agohover

okay, i see what you mean. "verbs" must mean that there's a register window where you poke commands into. in that case the state would have to be dumped out one register at a time by reading a single register over and over again while changing some kind of pointer. but how you got to that state would still be a mystery. in the case of a direct-mapped register interface, it would be obvious how to get there - you just write whatever values you read back into those locations. you'd need to have a logic/bus analyzer on the PCI bus and watch the driver configuring the chip to find the magic sequence. but still that wouldnt tell you too much about how to make the kext do the same thing.

Re: AppleHDA.kext progress

snickersmd 1223846042|%e %b %Y, %H:%M %Z|agohover

Well after a quick read, it would seem that they aren't much further than we already are. I did use codecgraph to derive the pin mappings and devices, in combination with the linux dump. Our config verbs are also done correctly based on the Vista registry dump and the Linux codec dump.

What is interesting is that they are starting research into the Post Construction Initialization and other DSP settings, which is exactly where we seem to be stuck. I would follow this thread closely and even apply some of the Mic and DSP settings from the tutorial to our kext.

Still very curious as to why the devices show up on my side but not with elroy, strongesthylian, or now toonces. Did anyone here actually get the devices to show up? Perhaps there is something wrong with the kext I uploaded?

Re: AppleHDA.kext progress

Toonces 1223875673|%e %b %Y, %H:%M %Z|agohover

snickers, maybe just to be sure you can grab the AppleHDA.kext that you have loaded on your machine that is showing the devices and upload it as a different filename for us to grab and try? I have tried the testingcodec several times today along with trying different DSP settings and all I've managed to do is make my system crash a few times. Of course it's easy enough to revert back to the testing file so it's not a big deal. I also played around with patching AppleHDA and using ALCInject and also with AppleAziliaAudio.kext. I do get sound on the headphones using the Azilia kext but that is it. Azilia also shows up as HD Audio device in sound pref pane but not a peep from the speakers. Beyond just changing the VendorID in Azalia, I don't know of any way to remap that driver so there's no way to get anything other than headphones. I know you don't want to waste time going through that but 1. It's frustrating not making any progress though I have spent a lot of time, I don't feel like I am any closer and 2. I would shove a quarter in the SD slot if I thought I could get audio out of the speakers :D

Re: AppleHDA.kext progress

mikeweiss 1223846281|%e %b %Y, %H:%M %Z|agohover

I am sorry I cannot be of more help. But I have been watching this thread closely. I installed the Kexts that you put here and I can confirm I do not get any devices. I will be ready to test and report on anything you guys upload.

Its all I can contribute, you are way over my head.

Thank you for your hard work.

Re: AppleHDA.kext progress

snickersmd 1223852122|%e %b %Y, %H:%M %Z|agohover

@elroy,

Just noticed from one of your posts in the other parts of this forum, are you using a 1000HD or a 1000H?

Also, what models is everyone trying this kext on?

Is it possible that Asus is screwing around with us by configuring the codec differently per model? Or even using a completely different codec chip that everyone just assumes is correct? One reason that this kext wouldn't load on a given ipis would be if the codec chip was completely different…

I suppose we should have a "sound off" (pun unintended, but ironic) as to models, distros, and any additional specs.

I myself am using a 1000H with 2gb of RAM and a 320GB HDD. I used iDeneb 1.1 as per MacEee.com. I have the 1005 modified BIOS installed. I have updated to 10.5.5. The kexts I am using include all those suggested by MacEee.com, with the exception of the battery and smbios kext changes offered in the wiki.

Re: AppleHDA.kext progress

elroy 1223861576|%e %b %Y, %H:%M %Z|agohover

Oh snickersmd, you've got to stay up to date with these things! :P

I got fed up with not being able to get OS X running on the 1000HD so I got rid of it and bought a 1000H and had Leopard running on it in no time.

I've installed a broadcom card in it and picked up a MacBook Air USB to ethernet adapter just yesterday.

I'm still on the stock 1gb ram chip, but plan to grab a 2gb stick shortly.

I'm running 10.5.5 from the vanilla 10.5.4 dvd and updated to 10.5.5 with the apple combo update.

Re: AppleHDA.kext progress

Toonces 1223876127|%e %b %Y, %H:%M %Z|agohover

18/M/Cali…Oh, wrong window…. 1000H, 1103 Modified, ideneb 1.3 all kext from maceee except Air SMBIOSEFI from IM forum and ACPIBattery from superhai.

Re: AppleHDA.kext progress

mikeweiss 1223852809|%e %b %Y, %H:%M %Z|agohover

1000h, ideneb 1.1, updated to 10.5.5, kexts from Maceee.com with the exception of the Air SMBIOSEFI (battery meter still isnt right doesnt give me percent just calculating) and an updated 950 kext. using DisplayConfigX to get it to 1024x600. Tried to install the kext from this thread but no output devices. i did notice in the system profiler I get Intel High Definition Audio: Device ID: 0x1043831A

I am using the latest modded bios from the usual place.

upgraded ram

is there an IRC room we should meet in to work on this more realtime?

Re: AppleHDA.kext progress

codeye 1223854784|%e %b %Y, %H:%M %Z|agohover

I'm using a 901 and the test kexts show devices which autosense here. Now that I have a better understanding of the pinconfig, it may be that we need to do something like what is required for some codecs under linux - ie power up the external amp, this could be done via "config verbs". Also some of the errors we are getting fit with the verb names under the relatek data sheets - this is pretty cool.

Last edited on 1223855290|%e %b %Y, %H:%M %Z|agohover By codeye + Show more

Re: AppleHDA.kext progress

Toonces 1223863632|%e %b %Y, %H:%M %Z|agohover

I am starting to think that you're close to the answer codeye. The one major difference with the ALC269 is that it has an internal amp instead of an external one though. I wonder if the reason we have no sound when people are getting the devices showing up in the sound pref pane is because the amp isn't defined or controlled properly. All of the other ALC chips so far have an external amp. The ALC269 does not.

Just for shits and giggles, I tried an older approach using HDPatcher 1.20 and ALCInject. I took the 1000H's linux dump and set the device is to the ALC262 and ran it on a stock 10.5.5 AppleHDA.kext. I then grabbed the patched AppleHDA.kext and modified all of the instances of 0x10ec0262 back to 0x10ec0269 (I also changed the deviceid's in the plist files to match) effectively making the patcher work on a file it shouldn't have. After I rebooted with the new AppleHDA.kext and ALCInject.kext, I get controls shown in the sound pref pane but no sound and no way to actually move the volume slider. When I highlight Internal Speakers or Headphones as output devices, I get The selected device has no output controls. Of course, with this method you don't get anything in System Profiler either or than the DeviceID and AudioID 12. Nothing shows as an available device but I don't think it does when the sound works either. I normally use HDAEnabler since it shows up then but thought I'd try an older approach and see what I got.

Between that and the errors we get on the testing kext, it sure looks like it wants to work but doesn't know or doesn't have an amp to control….

kext re-upload

snickersmd 1223896630|%e %b %Y, %H:%M %Z|agohover

As per Toonces request and in light of the overwhelming amount of people loading the kext without any devices showing up, here is a re-upload of my AppleHDA.kext, straight from my extensions folder so there's no chance for mixup. If this still fails, then something else must be the problem.

http://ipis-osx.wikidot.com/local--files/forum:thread/AppleHDA.kext.zip

Oh, and Toonces, don't lose heart — if you think you're frustrated after playing with it for a couple of hours, just wait till it's been days of fruitless hacking like me and codeye. ;)

Re: kext re-upload

nhirt 1223912531|%e %b %Y, %H:%M %Z|agohover

@snickersmd: I had the problem with the devices not showing on my 1000h. So I installed a "virgin" iDeneb 1.5
with only the GMA950 kexts and SwitchResX.
Then I loaded your latest AppleHDA.kext and nothing showed up.

After toying aroung a bit (for one I repaired the permissions and reloaded the kexts) suddenly the devices showed up
("Internal-" and "External microphone" and "Internal Speakers" that switch correctly to "Headphones" when plugging them in)…
Strange, could it be a file permission problem (though I don't think so)….?
Below my HDA-related error messages.

Nik

Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: HDAEnabler: Copyright (c) 2008 by Kabyl
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: HDAEnabler: 05/05/2008 Added SPAudio support:Taruga
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAPath.cpp" at line 1168 goto Exit
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 != pathSet->getWidgetAmplifierGainRange ( &zeroValue, &minValue, &maxValue, &minDB, &maxDB, kPATH_CONTROL_SPATIAL_CHANNELID_Master )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 248 goto handler
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAPath.cpp" at line 1168 goto Exit
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 != pathSet->getWidgetAmplifierGainRange ( &zeroValue, &minValue, &maxValue, &minDB, &maxDB, kPATH_CONTROL_SPATIAL_CHANNELID_Master )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 248 goto handler
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "false == pathSet->isAmplifierGainAdjustable ( kPATH_CONTROL_SPATIAL_CHANNELID_Master )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 3572 goto Exit
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 3527 goto Exit
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 != widget->setUnsolicited ( true )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDACodecGeneric.cpp" at line 830 goto handler
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit
Oct 13 17:26:22 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit
Oct 13 17:26:24 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit
Oct 13 17:28:01 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit
Oct 13 17:28:52 niklaus-hirts-macpro31 kernel[0]: Sound assertion "false == pathSet->isAmplifierGainAdjustable ( kPATH_CONTROL_SPATIAL_CHANNELID_Master )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 3572 goto Exit
Oct 13 17:28:52 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 3527 goto Exit
Oct 13 17:28:52 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit
Oct 13 17:28:54 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit
Oct 13 17:28:54 niklaus-hirts-macpro31 kernel[0]: Sound assertion "false == pathSet->isAmplifierGainAdjustable ( kPATH_CONTROL_SPATIAL_CHANNELID_Master )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 3572 goto Exit
Oct 13 17:28:54 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAEngine.cpp" at line 3527 goto Exit
Oct 13 17:28:54 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit
Oct 13 17:30:42 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == fExternalControlArray" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroup.cpp" at line 736 goto Exit
Oct 13 17:30:42 niklaus-hirts-macpro31 kernel[0]: Sound assertion "0 == controlRange" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/DspFuncLib/Functions/DspFuncVolume.cpp" at line 512 goto Exit

Re: AppleHDA.kext progress

codeye 1223897302|%e %b %Y, %H:%M %Z|agohover

tell me about it!

Re: AppleHDA.kext progress

codeye 1223912227|%e %b %Y, %H:%M %Z|agohover

Just playing with Snickers kexts on the 901 and a MacBook Pro with alc885. If I reduce the number of devices in platform info.plist then the number of fexternalcontrolarray errors decreases by the same number, the kext of course still loads but with less devices available. If I compare the IORegistryExplorer outputs on the 901 and the Macbook, our kext loads all the PinConfigurations in sequential order regardless of what is placed in pinconfiguration under HDAEnabler. On the Macbook (layout 56) only the pinconfigurations corresponding to the pin complexes that are identified under the various devices on the pathmap (pathmapid 16) are displayed. I think this suggests these errors are occurring because the incorrect pinconfigurations are being parsed (or at least blocked/corrupted by inactive pin complex data), funny thing is layoutid 56 has no representation in controller plist, so I'm not usre how the configdata is being passed on the macbook pro?

Re: AppleHDA.kext progress

snickersmd 1223925170|%e %b %Y, %H:%M %Z|agohover

@codeye
Some notes on my observations regarding the pin config verbs loaded to the IO registry:

I tried working with just our pin config verbs in HDA Enabler, but it would be overridden with what was in the controller plist. So then, I tried clearing the pin config verbs in HDA Enabler and putting them just in controller plist; the result was a blank IO registry. Therefore, I concluded that the pin config verbs should be loaded in both controller plist and in HDA Enabler in order to take effect.

I've also played around with why we arbitrarily use Layout 12 as a starting point for our hacking. Early on, I wanted to make a "minimal change" kext where I wouldn't delete stuff that wasn't used, find a set of layout and pathmap already in the stock plist that closely matched what I wanted and change just that, then change the enabler to point at this new layout instead of 12. It doesn't work - I think it's a limitation of the programming of the injector. The reason is that I wanted to use layout #56, which in turn has a hex value of 0x38. If you load hex value 38 into the injector, it calls layout #8 instead — because 0x38 is the character "8" in ASCII. So you can plug certain numbers into the injector, but they don't always behave right; best to use it as originally set up.

Earlier I did think that the pin config verbs should have a particular order and should only be loaded in a particular way so as to correspond with the devices, but I discarded the idea. Firstly, each set of config verbs is address-locked to their corresponding pin, so it shouldn't matter what order you load them in. Secondly, about half of the 11 config verbs in our setup are actually verbs that inform that a particular pin is not connected within a given configuration. Are these safe to leave out, or is it mandatory to declare which pins are not connected? From what I have seen of the other config verbs listed in controller plist, they also have non connected pins in the mix, so I decided to leave them. I have also tried playing directly with the verb values, but that didn't go anywhere. Honestly, since those came from a Vista system, where sound is working perfectly, I have little doubt that the pin configs are correct.

You've also brought up some more of the mystery surrounding the Apple plist config system. What the f* is the deal with several entries for the same codec, and pointing to layouts that don't seem to connect to anything else? (Also I thought the MBP uses a Sigmatel codec, not an ALC885, which is supposedly in the Mac Pro (desktop)) My guess is that certain layouts are aliased or linked to other layouts somehow, like they jump internally from one to the other during the init/config phase. On the MBP check to see where those verbs are coming from, might be from a totally different entry in the controller plist.

However, I'm not exactly sure that pin config verbs are even the problem area for us. Firstly, the default config verbs do nothing for the amps, and all the error messages are pointing to amps. My guess is that it really will boil down to finding out what the correct settings to deal with the ALC269 internal amp are. Seems that each device needs a "control group" and only two of those devices really seems to crap out on the amp.

@nhirt
Nice find with the permissions fix. I wouldn't be surprised if that was it, especially since the AppleHDA.kext is actually several kexts that have been poked and prodded rolled into one.

@everyone else
Now that we're all getting to the same page, let's try random plugging some amp values into the layout and see how the error messages change. Please remember to post what values you change here on the thread, so that other testers don't waste time with values that you've already tried unsuccessfully.

Last edited on 1223925794|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

comatron 1223929180|%e %b %Y, %H:%M %Z|agohover

im reading all this thread now for a long time. im a real noob in this stuff. i just wonder, if you cant take any advantages for the developing from my runnin azalia audio on the eee1000h. anywhere there in the kexts is the working stuff for the audio output … or am i totally wrong now? if i can help you by providing some infos from the running system - let me know …

Re: AppleHDA.kext progress

strongesthylian 1223929557|%e %b %Y, %H:%M %Z|agohover

The new kext you uploaded worked. The devices appeared and says headphones when you plug in a pair.

I will begin testing when I go to work today. Thank god for so much downtime there.

Re: AppleHDA.kext progress

codeye 1223942480|%e %b %Y, %H:%M %Z|agohover

Snickers,
I found a second copy of HDAenabler sitting in the AppleHDA kext and that was loading my configdata! I actually removed the ALC269 from controller plist and it still loads if HDAEnabler has the correct pinconfiguration - so does this mean for some codecs controller isnt used? I cannot run Vista on the MBP (not mine dammit) but here is the derived values that should load in vista, and they dont match any of the published list in controller plist - perhaps its hard coded in the controller binary?
01471c40 01471d01 01471e10 01471f90
01571c50 01571d40 01571e2b 01571f01
01671cf0 01671d00 01671e00 01671f40
01771cf0 01771d00 01771e00 01771f40
01871c10 01871d01 01871ea0 01871f90
01971cf0 01971d00 01971e00 01971f40
01a71c20 01a71d30 01a71e8b 01a71f01
01b71cf0 01b71d00 01b71e00 01b71f40
01c71cf0 01c71d00 01c71e00 01c71f40
01d71cf0 01d71d00 01d71e00 01d71f40
01e71c60 01e71de0 01e71e4b 01e71f01
01f71c30 01f71de0 01f71ecb 01f71f01
I wonder if we can get hold of the code for HDAEnabler that may be helpful.

Re: AppleHDA.kext progress

snickersmd 1223957162|%e %b %Y, %H:%M %Z|agohover

codeye,

You have me a bit confused by this post.

Firstly, that's not a "second" copy of HDAEnabler. You were supposed to delete any external ALC injectors or HDA enabler kexts. The best place for the HDAEnabler is where I put it, along with the patched AppleHDA.kext.

Secondly, I don't get what you mean that you removed ALC269 from the controller plist and still HDA enabler is loading correct configuration? The controller technically isn't used with any non-Apple codec, that's why we use HDA enabler to inject values and trick the controller into thinking we have a valid codec.

Thirdly, what are these values you posted? Are these from an ipis or MBP? From the stock plist, from a Vista registry dump found on another forum, or from IO registry?

Vista pin config verbs won't match config verbs found in Apple plists because they are byte-flipped in Apple.

Re: AppleHDA.kext progress

codeye 1223942615|%e %b %Y, %H:%M %Z|agohover

Comatron,
could you dump the pinconfiguration from ioregistryexplorer - that would be helpful!

Re: AppleHDA.kext progress

strongesthylian 1223958109|%e %b %Y, %H:%M %Z|agohover

@ people who were having trouble getting sound devices to appear:

Have you tried snicker's new test kext? Did it work? If not, I believe I've come up with the solution: I think some of the plugin kexts aren't being read. So I took those plugin kexts that don't begin with "AppleHDA" and installed them into the /System/Library/Extensions folder. After restarting, the sound devices appeared!

To make it easier, I've recreated the zip file for you to just open up and install the kexts. Let me know how it goes.

EDIT:
Totally screwed up the Contents alias. I think I got it right this time by making a symbolic link.
http://www.mediafire.com/file/gn3zydmzn04/hdatestpack.zip

Last edited on 1223961089|%e %b %Y, %H:%M %Z|agohover By strongesthylian + Show more

Re: AppleHDA.kext progress

strongesthylian 1223960262|%e %b %Y, %H:%M %Z|agohover

As far as testing goes, this thread is huge enough as it is. I think it would be a good idea to post results in a completely new thread.

Re: AppleHDA.kext progress

snickersmd 1223978697|%e %b %Y, %H:%M %Z|agohover

There's no need to separate the bundled kexts. As nhirt found, it is most likely a permissions error. You have only verified this by installing the kexts separately, as the kext helper changes the permissions on each kext as you install it. Apparently, the kext helper does not change permissions of the respective bundled kexts as well.

I will look into the permissions on my file, fix, and reupload if necessary.

EDIT: Looked into it and found, as suspected, entire kext had ownership as snickers:staff. Updated ownership to root:wheel, rezipped and reuploaded.

http://ipis-osx.wikidot.com/local--files/forum:thread/AppleHDA.kext.zip

Last edited on 1223979343|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

strongesthylian 1224006142|%e %b %Y, %H:%M %Z|agohover

Ah! Well I'm glad I could be of some help.

I left my laptop at work accidently and I'll try the new kext and also post the results from the console in the results thread.

Re: AppleHDA.kext progress

codeye 1223988896|%e %b %Y, %H:%M %Z|agohover

snickers,
I removed any reference to alc269 (283902569) from controller plist and the IOregistry only fills with what you put in HDAEnabler, and the kext still loads (is this obvious?). The MBP only loads half of the "pin default" values from the "pin complexes" seen on a ubuntu dump of the codec#0 (definitely ALC855) on the mbp when I fired ioregistryexplorer - so I've mimicked this with HDAEnabler. The pin defaults that load are those attached to active pin complex nodes.
I'm not sure what went screwy with my install but as you noted it doesn't matter what is in the PinConfigurations under HDAEnabler to load the HDAkext - so I wasn't on the right track there - drat! However it seems with the 10.5.5 kexts the configdata under controller plist now loads up the IOregister. The config verb list is already in "Apple format" - I guess I'm still miffed that the MBP loads all the right info without seeming to refer to the configdata list of any of the codecID 283904133 present in the controller plist - If I can mess around with the AppleHDA kext on the mbp I'll see if it is referencing HDAConfigDefault 20 which doesnt have a configdata entry and I might try screwing around with other parts of the controller and platform plists for the MBP and to see if it stops the kext from working and generates the same error messages.
I was away all last week and I was attempting to catch up quickly and didn't bother to look in the plugins section of your modified kext ;-) hence 2 HDAEnablers!

Re: AppleHDA.kext progress

snickersmd 1223995718|%e %b %Y, %H:%M %Z|agohover

What's really odd about the whole pin config verb thing is the fact that they're written down at all in the Apple plist. These don't come preprogrammed in Linux or Vista. A codec dump shows us that the pin configs are pulled from the codec chip itself. Also, Vista didn't just magically have every single pin config loaded in its registry, the UAA class driver pulled these from the codec chip and stored them there.

So if this information can simply be queried from the chip, why store it in a config file at all? I'm thinking, while default configs are offered in the plist, perhaps the kext is ultimately querying the codec on a MBP for the correct values which are then loaded into the IORegistry. Furthermore, since the driver looks for Mac hardware and doesn't find it, we have to do this ourselves and put only the right values in.

Could you provide me with the codec dump and IORegistry dump from your MBP? Perhaps we can find some correlation between actual default pin configs as provided by the codec, default pin configs as given in the stock plist, and default pin configs that actually get loaded in the IORegistry.

I'll also muck around with the pin configs on my Intel Mac Mini.

As a member of the wiki site you should have upload privileges to this thread.

Re: AppleHDA.kext progress

codeye 1224001370|%e %b %Y, %H:%M %Z|agohover

The other thing is we hack AppleHDA binary for ALC262, but of course none of the config file data is related to this codec. Which apple hardware has this chip? I tried to alter the plist files (short of deleting them!) and the MBP sound doesn't skip a beat.
A disassembly of AppleHDA shows a whole lot of verbs being called querying the codec info and alc262 subroutines. I wonder if we should compare the ALC262 and the ALC269 codec dumps to see if there are similarities and differences that we may need to address.
Still quite stumped…
I've uploaded all the files to the audio wiki page.

Last edited on 1224002016|%e %b %Y, %H:%M %Z|agohover By codeye + Show more

Re: AppleHDA.kext progress

snickersmd 1224004214|%e %b %Y, %H:%M %Z|agohover

My thoughts exactly… Most AppleHDA hacks out there try to force recognition of an 885, but when I saw in the disassembly that the kext supports the 262 I decided to go that route instead, since at least the 269 is in the same family. However, nothing in the plist seems to reference a 262, and I am unaware of any Apple hardware using the 262.

I don't know what we'd gain by looking at a codec dump of the 262, since there is nothing in the plist to match it to. After all, we are trying to find out what the plist does. The stock plist is given, the codec dumps for a stock codec are available, and what we have is the codec dump of our codec. Just by logical equivalence, we should be able to reverse engineer the stock plist given the stock codec dump, and apply that knowledge to our codec dump.

I did however, start looking at the 262 datasheet as soon as I had made my kext hacks.

Although it is logical to assume that the 262 is closer to the 269, what if I'm wrong? What if there is some initialization routine called by the 885 path that we need, given the correct path and layout? I don't know why I didn't think of it earlier, but could you (or anyone else) take the time to try using the plists we have now together with a kext patched for 885 instead of 262?

Last edited on 1224004564|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

Toonces 1224011385|%e %b %Y, %H:%M %Z|agohover

I don't know why but even after repairing permissions and trying every one of the posted kexts, I cannot get any devices to show up and there are no errors in the logs. Just that HDAEnabler loaded. Could it be because of the version of SMBIOSEFI I am loading? What about using EFI Strings to load the config files rather than HDAEnabler? Or should that be something to try later?

Re: AppleHDA.kext progress

snickersmd 1224040778|%e %b %Y, %H:%M %Z|agohover

You fixed permissions but did you also change ownership? The kext (and every kext inside, and everything inside those) must belong to root:wheel.

sudo chown -R root:wheel /System/Library/Extensions/AppleHDA.kext

Re: AppleHDA.kext progress

Toonces 1224047351|%e %b %Y, %H:%M %Z|agohover

ok, I changed ownership and verified permissions again and still nothing shows in the sound pref pane. I do get items in System Profiler for speakers, mic & hp jack though. I also changed the kext to use the ALC885 codec instead of the ALC262 using the last codec you uploaded. I did remove HDAEnabler from the AppleHDA.kext and am loading that separately. Here are the new errors:

10/14/08 9:57:58 PM kernel HDAEnabler: Copyright (c) 2008 by Kabyl 
10/14/08 9:57:58 PM kernel HDAEnabler: 05/05/2008 Added SPAudio support:Taruga 
10/14/08 9:58:01 PM kernel Sound assertion "0 == converterWidget" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroupALC885.cpp" at line 178 goto Exit 
10/14/08 9:58:01 PM kernel Sound assertion "0 != err" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDACodecGeneric.cpp" at line 154 goto ExitError 
10/14/08 9:58:04 PM kernel Sound assertion "0 == converterWidget" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAFunctionGroupALC885.cpp" at line 178 goto Exit 
10/14/08 9:58:04 PM kernel Sound assertion "0 != err" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDACodecGeneric.cpp" at line 154 goto ExitError

Re: AppleHDA.kext progress

comatron 1224012998|%e %b %Y, %H:%M %Z|agohover

here the ioreg of my workin 1000h azalia audio line out:

http://www.mediafire.com/?sharekey=0d7f0c4797378ca4d2db6fb9a8902bda

Re: AppleHDA.kext progress

codeye 1224072432|%e %b %Y, %H:%M %Z|agohover

Just had a quick look at the new AppleHDA.kext update for the new macbooks and it looks like even more layouts in the plists and some of the previous layouts that appeared hardcoded into the AppleHDA binary - I think this suggests Apple are trying to make the kext more generic - this may well be good for us!

Re: AppleHDA.kext progress

codeye 1224078892|%e %b %Y, %H:%M %Z|agohover

comatron,
thanks for the ioreg data. The one interesting thing that I can see is that the ioreg we are using has a different IODeviceMemory 0xf9db8000 (vs 0xfffffffff7eb8000 in yours) - maybe the errors are occuring because the HDA binary is not accessing the realtek chip? When I get a sec I'll see what numbers pop up when I try to load the azalia kext.

Re: AppleHDA.kext progress

Toonces 1224093894|%e %b %Y, %H:%M %Z|agohover

codeye, I get the same 0xf7eb8000 for the memory address on my 1000H using the testing and other AppleHDA.kext that I have tried.

Re: AppleHDA.kext progress

codeye 1224087407|%e %b %Y, %H:%M %Z|agohover

Yep tried Azalia kext and my ioregister is giving the same address as hdakext 0xF9db8000. The only other differences are IOInterruptspecifiers one byte different and some hdaenabler info. I will try loading a different version of HDAEnabler and see if this changes.

Re: AppleHDA.kext progress

Toonces 1224106288|%e %b %Y, %H:%M %Z|agohover

Just a few questions for you guys. HDAEnabler took the place of ALCInject as the preferred way to get config data injected. I assume that is because the AppleHDA.kext would not need to be edited so heavily as the config data appears to be injected by HDAEnabler. Am I correct? I grabbed a stock AppleHDA.kext off my macbook and before I did any edits at all it showed up exactly as all of the hacked ones did. No devices in Sound pref pane but shown in System Info and IOReg. Would it be better to blank out HDAEnabler or use ALCInject to see if the modded AppleHDA.kext changes are taking effect? I don't think any of the changes I have been making are actually getting done as it is.

Re: AppleHDA.kext progress

codeye 1224151799|%e %b %Y, %H:%M %Z|agohover

Toonces,
Yep I think wishful tthinking on my part I used Reggie SE from xcode to look at the memory addresses for the eeepc901 and the MBP and they look similar suggesting that the device memory is correct and just varies depending on the machine - oh well. HDAEnabler will fill IOReg and Sys Info, but it seems with the 10.5.5 kexts that if the controller plist has an entry for the 269 it will override the info enabler "injects". In enabler you have to write in the actual pin complexes to fill the Ioreg correctly (I guess it puts them in directly) whereas the controller plist uses the pin configuration setup (ala vista) and "parses" them to derive the pin complex info that shows up in IOreg. On the MBP only the pin complexes that correspond to the active NodeID show up in Ioreg, wheras with our setup all of them show up - I tried just delivering the active pin complexes to mimic the MBP and it does show up correctly in Ioreg but no change in the errors that are spat out. I would be interested if anyone has a second hackintosh with sound working via controller plist edits to see what shows up in IOregister explorer - could be helpful.
I didn't think AppleHDA.kext would load with ALCInject beyond 10.5.1 - let me know if it does.
Might be worth grabbing the latest AppleHDA from the new macbook updates and give them a go.

Re: AppleHDA.kext progress

Toonces 1224176917|%e %b %Y, %H:%M %Z|agohover

Hi Codeye, I do have a second hack. A Dell 530 Quad Core w/ ALC888 audio that uses HDAEnabler. The biggest difference I noted was that in ioreg it shows up at a different address (no surprise there) and the acpi-path shows it as an AZAL device vs HDEF. I did try ALCInject with the AppleAzalia kext and I too got sound out of the HP jack just as comatron did. I did not look at it in ioreg at the time though to compare how it worked compared to what we have though. I also noticed the same thing about pin configs on my macbook. Only the active ones show up.

One step closer

snickersmd 1224155973|%e %b %Y, %H:%M %Z|agohover

Toonces and codeye:

I'm afraid you may be looking in the wrong place. For one, why are you going as low level as device memory? Studying the Intel HD architecture, you have to realize that any driver for an Intel HD Audio implementation does not deal directly with codec. It universally deals with the Intel chipset, and sends the command verbs through there.

Pin config is looking to be less and less relevant, as this is information that is extracted from the chip. Yet the verbs that are sent are not determined by this default configuration, but by the information presented in the layout and pathmap. How do I know this? Read your console error messages. It fails to "GetAmplifierGain". You were both right when your earlier findings pointed to the attempts to control an amplifier that wasn't there. Unfortunately from there you went off track, going back to pin configs. The pin configs deal with the routes for the sound devices. Again, if they were incorrect, the devices wouldn't load.

I revisited the amp settings instead. If you examine the pathmap, there is a field for an amp on the middle node of the group. However, the data sheet, as well as the linux codec dump, point to an amp on the source node, not the middle (mixer) node. The reason that amp setting is in the middle is because it was copied over from pathmap 16 for the ALC885, and I assumed that center value was where the amp is. Turns out our amp was not in the right place. I put the values for the amp in the right place, and all of a sudden, I can control volume, and all the error messages go away.

While you were looking at the pin configs, the Azalia ioreg dump provided by comatron gave me a crucial clue. Only one output device is created, and it had audio level (volume) control created. Ours didn't, until now. I was hoping that by obtaining volume control we could put this to bed, but no dice.

Now that our amps are in the right place, I have gone in and started to put the DSP settings back in for both inputs and outputs, and on the plus side, i have had no crashes, and all the error messages have gone away, except for one. It refers to "SetUnsolicited" as failing. If you search the ALC269 datasheet, this corresponds to the node that handles jack sense — the one which tells us when headphones are plugged in or not. The datasheet suggests that this has something to do with the GPIO setting — the MuteGPIO setting in the IntSpeakers layout still gives me a bit of grief. We need to find out what needs to be in this field. And if this experience has taught me anything, it's that we aren't missing any of the data. Each time I have found something "new" it has always been there in the codec dump, datasheet, and Intel specification. So we already have everything we need, we just need to know how it all fits together.

Now that the error messages are clearing, it means the pathmap and layout are coming even closer to completion. If, after all the errors are cleared, we still have no sounds, then I would go back into the pin configs. Until that point, I don't think you would get any results with messing with those as it seems that its the layout and pathmap are processed first and failure here stops the entire process.

Uploading my latest kext work to this thread.

Re: One step closer

Toonces 1224177748|%e %b %Y, %H:%M %Z|agohover

Hi Snickers, I don't think you should take the look into the device memory as looking in the wrong place. I just happened to have ioreg open when I saw codeye's post and told him what I saw on my 1000H. If he's using a 901 that could certainly account for the difference in device addresses but it's more just talking out loud about what we see since. I've actually been busy trying to understanding HDAEnabler and working on modifying a stock AppleHDA.kext rather than working on a previously hacked one. I did wander down that road for a bit without success (BTW, the hacked ALC268 kext I messed with was using the ALC885 codec) and the thing that strikes me is that in a stock AppleHDA.kext there are multiple layout entries for the same codecid. The hacked ones have all been trimmed down to just the 0 layout and I think may be why we are missing little bits. Yesterday I also broke the AppleHDA.kext out of the Macbook 2.1 update and started applying the patches to it. It's interesting that one of the 2 other layouts for the 885 have different pin cofigs listing. 1 keeps the originals and adds to it and the other one appears to just replace the pin config with just 2 pins. I don't know. I tried to upload the latest AppleHDA.kext from that update but I am not a member so I was unable to.

On another note. I have yet to be able to get any devices to show up in the sound pref pane. My permissions and ownership are correct but I still get nothing. I think it may actually be something else like SMBIOSEFI that is causing the issue though. Which SMBIOS are you running? I may try that and see if there is a difference.

Anyways, I grabbed the file you just uploaded and will start porting it over to the latest AppleHDA.kext from the update and see if I can get any further.

Re: One step closer

snickersmd 1224183024|%e %b %Y, %H:%M %Z|agohover

:) What I meant by "looking in the wrong place" wasn't where you were looking per se, not the device memory nor the extended looks into pin config or HDAEnabler. I was gently reminding you that you should correlate your tests with the error messages that show up in your console. Even if I have already looked at those things it's also important that as a community you have your own looks because you might catch something I haven't, and vice versa. Either way, we have to be systematic, so your testing should be targeted based on what we see in tangible evidence — our console error messages.

You should know that the kext that I put out was modified from stock. We have this level of progress simply because I decided that previously hacked kexts weren't getting us anywhere, and I had to start from scratch. By all means, continue your experiments if it helps you understand more about how this works, but be aware that the kexts I've been uploading are all direct modifications made by me, not working off a prepatch.

HDAEnabler only opens the door. It injects the basic configuration. I've seen cases on the netkas forum where they use it to inject even more than just the pin config and layout id, but this is only applicable with supported codecs where EFI strings can be used to completely configure the codec. That is not our case — hacking is necessary. For us, all HDAEnabler does is help us masquerade as Apple hardware. If you don't use it, the driver doesn't load because it doesn't find an Apple-built sound system. If you do, all you have is the driver loading. The next step is to configure it.

About "missing bits", I don't think that's the case. I have also wondered on this thread about why there are multiple entries for the same codec. However, all it could mean is that Apple uses the same codec configured slightly differently per model. I've also reverse engineered the cases where they load only two pin config values instead of all of them, etc. and it was mostly to change the state of a single device like the microphones. Now I have stated before that I tried to go with a "minimal change" approach, but the results are unpredictable with unexpected things loading to nothing loaded at all. For this reason I also decided to clear out the layouts as the hackers that came before us have.

As confusing as the kexts, their plists, combined with HDAEnabler can be, I don't think it has to be so very complex, making it jump from config to config. I mean, all my testing has shown that the make or break errors happen from what's in the pathmap and layout, so logically, we have to tweak that first. The thing to remember is that we can't just run tests based on whether or not we hear sound — that's the end goal — but systematically we have to clear each error one at a time to get to that goal.

Your other question, about my SMBIOS — I'm using the MacBook SMBIOS mentioned in the wiki. I am quite concerned that none of these kexts have yielded any devices for you. Are you sure you don't have any other hacked audio kexts loading? Did you clear your extensions cache? Using terminal, can you verify the ownership and permissions of each kext inside the AppleHDA main kext?

Re: One step closer

Toonces 1224269679|%e %b %Y, %H:%M %Z|agohover

I replaced the SMBIOS with the macnub one and I still don't get anything in the sound prefpane. It's got to be some different kext I am loading as compared to your install. I used ideneb 1.3 as a starting point but used different SMBIOS and GMA950 kexts. I'm not opposed to reinstalling if it will get me closer to what you have. I have verified permissions on every file in the AppleHDA kext that you last uploaded. I clear the extensions cace, reboot with -f, everything I can think of and nothing shows in the audio pref pane for me. Ever. It's all there in the System profiler and in IOReg but nothing in the sound prefpane.

One thing I wonder, is the HDEF driver the correct one? I checked my other hack (ALC888) and it is using HDAEnabler and AppleHDA.kext but the acpi-path says it's using AZAL vs. HDEF. From what I could find, the IOPCIMatch may determine which it uses. MadTux posted this

Yes that is also correct, but in the first place don't put nothing in your Controler plist, remove your codec id from that , this one have IOPCIClassMatch set to AZAL AND HDEF support (0x04020000&0xFFFE0000 0x04030000&0xFFFE0000)
But later after U are shure your AppleHDA.kext is working, U can test various pinconfig inside,
But real deal would be to know how to calculate your real pinconfigdefault

The above was taken from this post: http://forum.insanelymac.com/index.php?s=&showtopic=127227&view=findpost&p=900258

But our AppleHDA only has the first IOPCIClassMatch. I don't know if he has them in the same order as listed but on my 1000H I see HDEF as the selected item (driver?). Sorry if I am not being clear or seem to be jumping around. I am following your path but not getting the same results yet so I am also comparing my working configs to what is in the kext you uploaded.

Last edited on 1224269767|%e %b %Y, %H:%M %Z|agohover By Toonces + Show more

Re: One step closer

snickersmd 1224286310|%e %b %Y, %H:%M %Z|agohover

Toonces,

You keep mentioning that you checked the permissions, but did you check ownership? You haven't mentioned ownership at all and it is an entirely different parameter aside from permissions. How are you checking permissions and ownership — via terminal I should hope. All files inside, especially "sub"kexts (inside AppleHDA.kext/Contents/Plugins, and the files inside those kexts) have to be owned by root:wheel. Use "ls -Rl" in the terminal to verify.

HDEF is the correct device. AZAL was used by the previous Azalia kext and should no longer be used. If you have an AZAL in your IOregistry, it may explain what is going on. Perhaps you have an Azalia installation that you are not aware of, placed by iDeneb perhaps? The only explanation for an AZAL device is that you have Azalia loading, so you must find and remove it. You need to get rid of any Azalia files, ALCInject, or HDAenabler that you may have. HDAenabler is needed for our purposes, but is already provided inside the AppleHDA.kext that I have made available.

Calculating correct pinconfig as per MadTux is only his process of taking it from the Linux codec dump, assuming that you do not have the pinconfigs from a Vista registry dump. Since we do, then his step here is not applicable to us.

I do not think this is an issue of configs for you, it is obvious the driver is simply not loading properly for you. Only explanation I can think of is either the sub-kexts do not have proper ownership and permissions, or you have a rogue Azalia installation that is seizing device control. If configs were an issue, you would at least see relevant console errors, to which you have attested that there are none.

You may also try to do what strongesthylian did, by pulling all the subkexts out and installing them directly into System/Library/Extensions using the kext helper, which also verifies permissions and ownership. If it works after that, you can put all the kexts back inside AppleHDA.kext's plugin directory where they belong.

Re: One step closer

Toonces 1224290382|%e %b %Y, %H:%M %Z|agohover

by permissions I mean the ownership and permissions on the files is correct. Yes, I use terminal. I am very familiar with using OS X and unix in general as I am a sysadmin during the day (and a lot of nights too) with around 40 FreeBSD servers that I am soley responsible for. I have checked every single file and all sub files in the kext and they are all owned by root with the proper permissions (644 if I let diskutil repair them, 755 if I use OSXTools and I even tried 777 myself). There are no other audio kext installed.

As far as AZAL vs. HDEF. I'm not talking about the difference in using the older Azalia kext vs. the AppleHDA. Take a look at what I posted in my previous reply. It has nothing to do with the older kext. It has to do with AppleHDA.kext. MadTux wrote "this one have IOPCIClassMatch set to AZAL AND HDEF support (0x04020000&0xFFFE0000 0x04030000&0xFFFE0000)" This is referring to AppleHDA.kext. Here's the acpi-path entry from my other hack w/ALC888 using HDAEnabler.kext & AppleHDA.kext:

"IOACPIPlane:/_SB/PCI0@0/AZAL@1b0000"

and my 1000H running your AppleHDA.kext with ownership & permissions corrected:

"IOACPIPlane:/_SB/PCI0@0/HDEF@1b0000"

So my question is regarding whether or not the kext you're working on should have both IOPCIClassMatch addresses in them.

I'll give a try to pulling out the sub kext but I am thinking it must be a different kext loading than what you have. Video is my next one to check as I am using a different one that is from 10.5.5 that has been modified to work rather than the earlier one that is listed on the wiki.

Re: One step closer

snickersmd 1224293571|%e %b %Y, %H:%M %Z|agohover

Ah, okay. I of course only wanted to clarify what you meant, because between IT folks, a post that doesn't spell everything out either means you're abbreviating/shorthanding everything because you assume that we're all on the same level of understanding, or your post lacks detail because you don't really have a clue what you're talking about. Glad to know your experience puts you in the former category rather than the latter. ;)

About MadTux's statements, I don't think there's any need to add anything to the IOPCIClassMatch. I didn't touch the field, and yet it loads on my side. Older Intel HDA setups identified themselves as AZAL rather than HDEF, and I believe he is just stating that the kext should be able to recognize both. In the case of the ipis and AppleHDA, it should not show up as the AZAL, and there should be no need to adjust the class matching field.

Actually, I'm looking at the comatron ioreg dump now, where he is using the older Azalia kext but the identifier is still HDEF. I think the question as to whether or not the audio is seen as AZAL or HDEF depends on the Intel chipset being used (ICH6 vs ICH7, etc).

I think there was one earlier poster who stated that he reinstalled everything before he got the AppleHDA kext to load devices. I sure hope you don't need to do anything that drastic just to get to where we are. Somehow I doubt that it has anything to do with your video kexts, but I do agree that something must be different with your install compared with ours. I will eagerly await the results of you installing the subkexts separately.

Re: One step closer

Toonces 1224309599|%e %b %Y, %H:%M %Z|agohover

I did a reload of ideneb and installed all of the recommended kext in the wiki and installed your kext. I made sure the ownership and permissions were correct and rebooted. Same thing as before. Nothing in the pref pane. I had some time to kill waiting for my son's band practice to get finished so I connected to the internet via BT to my BB phone and downloaded your latest kext again. I put the newly downloaded kext into a folder on the desktop and removed all of the sub-kexts, set ownership on every sub kext seperately (vs. doing sudo chown -R root:wheel AppleHDA.kext), put them all back in to AppleHDA with the exception of HDAEnabler then installed them with kext helper and rebooted with -v -f and the devices now show! I checked the ownership and permissions again once the devices showed and there is no difference in terminal as before. Very Strange. Maybe it is showing inherited ownership?? It's also possible that even though there's no error messages that the permissions were not setting correctly if it was done in the Extensions folder?

Anyways, off the bat, one thing I see missing is mute. It may be related to the GPIO but I think it's more likely a setting in the controller plist. Another place you can look at audio settings is in the Audio Midi Setup app in the utilities folder. I like to look at that app because it gives you the current volume per channel and just a little more info than the audio pref pane. Mute is also grayed out there as well. I have it on the charger now (no brightness control is brutal on the battery) and can finally start making adjustments that may actually do something! Woo Hoo

Re: One step closer

Toonces 1224311329|%e %b %Y, %H:%M %Z|agohover

ok, now that I have something to work with I see that the pathmaps for audio out are missing. Under pathmapid 16 there are only 3 pathmaps and according to MadTux's directions, those are for mic, line in and spdif in. I am going to add the ones for int speakers (3) and headphones (4) and see if I can get those working. It looks like I may have to re-arrange the 0,1 &2 that are there so they line up with the correct functions. At the very least, I don't think speakers and headphones are supposed to be under the same pathmap node.

Edit: I managed to change the error message and boot to a blue screen :D

Last edited on 1224313087|%e %b %Y, %H:%M %Z|agohover By Toonces + Show more

Closer Still?

Toonces 1224319259|%e %b %Y, %H:%M %Z|agohover

ok, I think I am getting much closer to having things correct. I compared your latest kext against my working hack codec and I added the output pathmaps and arranged them in the same order as my ALC888 hack has. According to what I see, my ALC888 has the same Int Speakers and Headphone pin configs as the ALC269. I also added a missing MuteGPIO in the layout for line in. I also changed the pin config order for IntSpeakers as it appears to be backwards in your kext. At least when I compare it to my ALC888 which has the same pin configs. I may have intspeakers and headphones reversed in the layout order but they are identical in the pathmap setup other than the actual pins in use so worst case I would get speakers by selecting headphones. I think I found the config for the headphone sense but cannot find where I saw it now :( It's getting late and I have to be up early to get my son to a competition. In my latest edit I messed something up with the volume control but everything else looks correct now and I have mute for my silent eee :). I wanted to upload the kext where I have it so someone could look it over and see where I might have made an error in entry but I cannot upload files here.

Very Basically, what I see is that the pathmaps correspond in the order listed in the layout inputs first then outputs. i.e. if the layout specifies LineIn then Mic and outputs specify Headphones then IntSpeakers then there should be 4 pathmaps in the order of LineIn,Mic,Headphones & IntSpeakers. That is where I have the kext at the moment. According to what I see in my ALC888's files, the Amp goes in item 1 on the inputs and item 2 on the outputs. Of course, that could be different for this chip but that's what I did since the pinouts for the outputs are identical. I think if I can figure out what I did to the volume control I may have a shot at working sound of some type. I also have to find my headphones that my other son "borrowed" so I can test that :D

snickers, if you'll make me a member I will upload what I've got. I hate to leave it like this because I feel I'm close but it's nearing 2AM and I have to be up in 4 hours (I did say most nights didn't I?)

Toonces

Edit: What pin is the hp sense on? Also, I didn't look. Is this kext using the ALC262 or ALC885 codec?

Last edited on 1224319494|%e %b %Y, %H:%M %Z|agohover By Toonces + Show more

Re: AppleHDA.kext progress

snickersmd 1224156182|%e %b %Y, %H:%M %Z|agohover

http://ipis-osx.wikidot.com/local--files/forum:thread/AppleHDA.kext%202.zip

Latest kext is here. Assignment is to find the right GPIO setting for the internal speakers and headphones.

Remember to change ownership and fix permissions after install.

Last edited on 1224159322|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

comatron 1224172431|%e %b %Y, %H:%M %Z|agohover

proud that i could help with my noobish skills … we´re moving forward thanx to your all hard work… keep it up !!! i thank you

Re: AppleHDA.kext progress

snickersmd 1224322512|%e %b %Y, %H:%M %Z|agohover

@Toonces:

Glad to hear things are finally accessible for you. A member invite has been sent as well.

Actually, I don't agree with MadTux/Taruga on their structure of the pathmap for the ALC269. If it actually makes things work for you to redo my pathmap work, then so be it. However, take into consideration the unique conditions of the ALC269.

Firstly, the ALC269 has no SPDIF in. At all. So it should not be reflected in the layout or the pathmap. Secondly, the ALC269 is weird in that it has 2 SPDIF outs. Neither is connected in the ipis, so they are also not reflected in the layout or pathmap.

Thirdly, the output pathmaps are not missing. I purposely nested them together as a function group. I am almost certain that the pathmap is an xml representation of audio function groups as defined in the Intel HD Audio Specification. In Vista, the Internal Speakers and Headphones are NOT presented as two separate devices. Recall that the Vista UAA Class driver reads the proper configuration directly from our codec, and correctly for that matter since it's the only operating system and configuration with perfect sound. It specifically has 1 output device, with two possible output paths (internal ATAPI and headphone external jack) and 2 input devices, specifically termed as Microphones and not as Mic and Line Out. To schematically represent these outputs as separate devices in the pathmap is incorrect. If you study the other stock pathmaps, you will see other examples in which several pin widgets are grouped together to form a single function group. Conclusion: Vista works, and sees 3 devices. Therefore, our pathmap should only have 3 devices, with one (the output) being a compound device made up of the speakers and headphones. Again, even if my ideas are theoretically sound, please continue your experiment as you see fit because who cares about matching the spec if your methodology arrives at audio finally working? ;)

I do respect MadTux (props!) for publishing a guide but I'm afraid I wouldn't use it as anything authoritative. His guide specifically reverses and explains the methods as observed by the operation of the Taruga patcher, with the addition of the pin config addons. (In other words, MadTux is more the preacher than he is the prophet) No other sub-group in the OSX86 scene that I have found in my searches for information has had to custom build a layout and pathmap from the ground up. Nor has any other group had to deal with such an esoteric codec chip that is way off of what Apple puts in their systems. If we were not standing on the cutting edge of AppleHDA hacking, then surely they would have had a working driver for us long ago. That is why you will find plenty of stuff that is in that guide that I chose to do differently. I suggest you read the Microsoft UAA docs and the Intel HD Audio specification as a better reference than the MadTux guide.

More evidence that ours is a truly custom pathmap and layout: you pointed out that in the ALC888, the amp is on item 1 in the inputs and item 2 in the outputs. This is based on an assumption that the amp location is static and comparable to the stock ALC885 plist. As you will see from my previous posts, I have specifically found that item 2 is the wrong place for the amp for our setup. Absolute true setup will not be found in a guide to another chipset nor the stock plist; the key will be in our own Linux codec dump, specific to our audio chipset.

I am impressed that you have found working MuteGPIO settings. They were missing on purpose, since every value I had plugged in by copying from stock managed to stall my boot and give me a crapload of error messages. It was my assignment to the group to try to derive these settings.

To derive the proper node for the pin sense, refer to the codec graph in the wiki, the Linux codec dump, and the ALC269 datasheet.

One thing you might want to play with, the source path nodes for Internal Speakers and Headphones may need to be switched around. Again, refer to codec graph to see why I couldn't be sure about which way the sound was going. The testing kext I've uploaded uses the routines for the 262. I encourage you to test using patches for the 885 instead, to see if it makes a difference.

Last edited on 1224322908|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

Toonces 1224376233|%e %b %Y, %H:%M %Z|agohover

ok, I have played around with different configurations and am not really making much headway. The only error I am at now has to do with pin sense which should absolutely not affect speakers and headphones. I decided to tackle the pin configs using the knowledgebase post over on insanelymac by The King. I am also using the intel docs to guide me. I did not use a script to do the linux codec. I am following it node by node and doing it by hand so that I know exactly what is there. I've also asked for a dump using the latest eee ubuntu with all of the audio fixes by adamm over on the eee forums so I can verify that the codec I am looking at is the same as there have been fixes that may have changed the output some.

LINUX
01171CF0 01171D11 01171E11 01171F41 - DA=F, Seq=0. Color=Black, Presence=No. DD=Speaker, CT= 1/8 Jack. PC=Fixed Function, Location=External Rear.
01271C20 01271D09 01271EA3 01271F99 - DA=2, Seq=0. Color=Unk, Presence=No. DD=Mic In, CT=ATAPI Internal. PC=Fixed Function, Location=ATAPI Internal.
01471C10 01471D01 01471E13 01471F99 - DA=1, Seq=0. Color=Unk, Presence=No. DD=Speaker, CT=ATAPI Internal. PC=Fixed Function, Location=ATAPI Internal.
01571C1F 01571D40 01571E21 01571F01 - DA=1, Seq=F. Color=Green, Presence=Yes. DD=HP Out, CT=1/8 Jack. PC=Jack, Location=External Rear.
01671CF0 01671D11 01671E11 01671F41 - DA=F, Seq=0. Color=Black, Presence=No. DD=Speaker, CT=1/8 Jack. PC=Fixed Function, Location=External Rear.
01871C30 01871D98 01871EA1 01871F01 - DA=3, Seq=0. Color=Pink, Presence=No. DD=Digital Other In, CT=1/8 Jack. PC=Jack, Location=External Rear.
01971CF0 01971D11 01971E11 01971F41 - DA=F, Seq=0. Color=Black, Presence=No. DD=Speaker, CT=1/8 Jack. PC=Fixed Function, Location=External Rear.
01A71CF0 01A71D11 01A71E11 01A71F41 - DA=F, Seq=0. Color=Black, Presence=No. DD=Speaker, CT=1/8 Jack. PC=Fixed Function, Location=External Rear.
01B71CF0 01B71D11 01B71E11 01B71F41 - DA=F, Seq=0. Color=Black, Presence=No. DD=Speaker, CT=1/8 Jack. PC=Fixed Function, Location=External Rear.
01D71C2D 01D71D82 01D71E05 01D71F40 - DA=2, Seq=D. Color=Purple, Presence=Yes. DD=Line Out, CT=Optical. PC=No Physical Connection, Location=NA
01E71CF0 01E71D11 01E71E11 01E71F41 - DA=F, Seq=0. Color=Black, Presence=No. DD=Speaker, CT=1/8 Jack. PC=Fixed Function, Location=External Rear.

Edit: Just finished decoding the dump. Here are the definitions.

BIG EDIT: I originally had a comparison to a dump from Vista but after I looked closer and double checked, I was using the wrong vista dump which was different.

Last edited on 1224388796|%e %b %Y, %H:%M %Z|agohover By Toonces + Show more

Re: AppleHDA.kext progress

Toonces 1224399575|%e %b %Y, %H:%M %Z|agohover

Ok, So I've had a lot of time on my hands today and think I might actually be caught up to where you are Snickers :) After getting the second linux dump from a 1000H and hand coding it, I am confident that the pin configs are right. I still don't think they're supposed to be nested though. One thing that caught my eye in the Intel specs is regarding the DA & Seq numbers. Basically it says that even though they have the same DA but a different Seq, the items should still be represented individually. I don't know if that applies directly to nesting the Speaker and HP outputs but I have a feeling that there should be 4 devices and not 3. When I added in a placeholder item I got all kinds of ugly errors but when I have it split out to 4 devices I get just the unsolicited error which is the HP Out Sense.

I have the ALC269 & ALC268 block diagrams and they are sooooo similar it's not funny. Hell, the outputs of the ALC268 speakers are even amplified just not a class D amp that makes the 1000H sound SO much better than the laptops that use the ALC268. I do see a few differences which is where it seems you have made an educated guess as to where the amps go ;) From the block diagrams it's fairly obvious they moved the amps for input from the middle to the last node. I was going to say that I thought it was strange that HP Jack doesn't work because it looks functionally unchanged but I see now that the mixer stage changed from a single node at node 0x10 to 2 seperate mixers at 0xD & 0xC. Maybe that's where we nesting is needed??? Anyways, I am going to keep playing around and see what I come up with. Maybe now that I have the diagrams I can figure out where stuff goes a little easier.

Re: AppleHDA.kext progress

snickersmd 1224403817|%e %b %Y, %H:%M %Z|agohover

Glad to hear it. Funny how a little over a week ago I was trying to round up people to help out from a common starting point, only to find that so many people had a hard time with the kext I put out just to get to that starting point. Now that you see what I see, we will be able to distribute our efforts more effectively.

My argument for 3 devices instead of four comes from Vista. I am dual booting Vista and I can fetch screen shots of their Audio properties pages that should definitively show how the devices should be mapped out, at least logically. (But it will have to come later, as I am running something now that won't let me reboot) Unfortunately, the pathmap file is a creation of Apple, and without documentation it is a matter of guessing the way that their file layout matches up with the specification.

If you set the pathmap up for four devices instead of three, do you still have a single output device that switches over depending on whether or not the headphones are in? Or do you have both Speakers and Headphones represented in the Sound Preferences Pane? According to Vista, you should not have two output devices, just one. If your separate representation in the pathmap ends up yielding two separate output devices, it's simply wrong… unless it works.

(Funny that I have to base correctness on what Vista does, ugh. Unfortunately, Microsoft did write the UAA side of the Intel HD Spec, and since the ipis' ALC269 is Windows Logo compliant, my contention is that we are getting AppleHDA.kext to plug into what was intended for the UAA Class Driver.)

I'm curious about these error messages you say you get when you attempt to nest a placeholder device. If the nesting is wrong, then how come on my side, the devices load up fine AND I only have one error message, the same Unsolicited message you're seeing. Either you're doing something wrong, or I am, or perhaps the whole discussion is simply moot: it's possible that the AppleHDA.kext is not as strict with pathmaps as we think it is. Let's upload console message logs in their entirety, shall we?

10/19/08 12:52:52 AM kernel HDAEnabler: Copyright (c) 2008 by Kabyl 
10/19/08 12:52:52 AM kernel HDAEnabler: 05/05/2008 Added SPAudio support:Taruga 
10/19/08 12:52:54 AM kernel Sound assertion "0 != widget->setUnsolicited ( true )" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDACodecGeneric.cpp" at line 830 goto handler

By block diagrams, do you mean codec graph? Or do you mean the diagrams in the datasheets? Because a codec graph taken from my own ipis has always been downloadable from the wiki. My assumptions as to where the amps are come from both the error messages that I got (or didn't get, after putting them in the right place) and by reading the Linux codec dump.

Much of my understanding came from comparing the stock pathmap for the ALC885 to a Linux codec graph of the same codec, where you can diagrammatically see the connections from node to node.

Re: AppleHDA.kext progress

Toonces 1224446265|%e %b %Y, %H:%M %Z|agohover

I think it's a moot point of 3 vs. 4 devices because it looks like both work. When I setup for 4 devices I get 2 output devices to choose from in the sound pref pane. When I added in a placeholder item it either pushes the devices out of order and there are errors because the devices don't line up or if I add it at the end, it errors because there's no device in the layout to match. I just looked at my macbook and it's nested there too and there is only the 1 device in the sound pref pane so nesting is probably the way it was intended to be. I didn't get the member invite so I can't upload but when I can, I can upload an ioreg dump of the macbook if it will help. If you have an unmodified AppleHDA.kext around, take a look at layout id 22 which goes with pathmap 1 (depending on the version of plist editor you are using it could be pathmap 0). That is what my macbook is using. It's using the stac codec that I think I read that some of the Apple notebooks use the stac codec even though the chip is an ALC. No idea really but if you look at that layout & pathmap you can see the nesting and that there's more than 3 nodes in a given step than just 3. That may be what is missing for us. We have 3 nodes defined for HP Out as an example but it could be more. Maybe for the pin detect or the second pcm out line that also feeds the speakers. The codec graph shows those as connected lines but we are only using 1 of 2 possible paths for output sound. look at those block diagrams and you'll see what I am talking about

I have all of the items you uploaded and have looked at all of them. I used the codec graph to look at how the codec says it's hooked up and then the block diagrams from the ALC269 Datasheet. I grabbed the datasheet for the ALC268 to use as a comparison and you can see exactly where things have changed. Of course, that is providing that Realtek accurately depicts their chips :). The block diagrams show the node id too so it's a good reference. One addition I see from the block diagrams is the equalizer in the speaker output in node 0x14.

About plist editor. If you are using version 2, numbering starts at 0. If you are using version 3 that comes with the latest xcode download, numbering starts at 1. version 3 lets you do nice things like cut and paste items between nodes. The numbering difference threw me off at first but if you keep that in mind, version 3 is the easiest to use to copy things like the Amp between nodes. I didn't see any of that ability with version 2.

I'll try to post my errors but am not always able to depending on where I am working and whether or not I can access the internet. I carry my 1000H pretty much everywhere and work on it when I have a few moments and may not be able to post the errors. The error you posted above is the same one I get with 3 or 4 devices if they're laid out so the items match up.

Re: AppleHDA.kext progress

codeye 1224468613|%e %b %Y, %H:%M %Z|agohover

Hi guys,
Just an update on what I'm doing at present. The problem with what we are up to as I see it is that despite loading the drivers and apparently having access to volume controls nothing is happening. But its kind of an all or none outcome.
In linux they have the hda-verb utility for troubleshooting.
On the mac we can do the same thing - but in a more cumbersome way. Using reggie from xcode you can easily manipulate memory and it dynamically updates. Codec verbs can be sent directly to the realtek chip at address 0x60 offset from iodevice memory - 0xf9db8000 on the 901. If you then set register 0x68 to 1 it passes the command and displays the result in 0x64. I've only just started this but it will probably be useful (it already suggests that the correct node for the hp is probably 12 and not 13). It would likely be very insightful to see how comatrons chip is setup for azalia hp (as this is working) versus how it is set for hda hp.

Last edited on 1224469278|%e %b %Y, %H:%M %Z|agohover By codeye + Show more

Re: AppleHDA.kext progress

Toonces 1224471634|%e %b %Y, %H:%M %Z|agohover

Hi Codeye, That sounds great. I think you'll find the block diagram from the ALC269 datasheet to be very helpful as well. You can grab it here: ftp://66.104.77.130/pc/audio/ALC269_DataSheet_1.1.pdf

Looking at the datasheet block diagram, it shows both node 0xC & 0xD are connected to the HP Out so it's very possible that either could be the source for the HP though node 0xC (12) is listed as LOUT1 and may be the primary path? I haven't done much today but plan on it during the week. I think that Snickers nested pathmaps are probably the correct way to go so I'll be grabbing his latest kext again since I hacked the hell out of the one I was playing with in learning more of what is going on.

Re: AppleHDA.kext progress

Toonces 1224525006|%e %b %Y, %H:%M %Z|agohover

@codeye, Could you write a quick and dirty tutorial on exactly what you do with reggie? I think I understand but want to be sure. If you could use querying for EAPD as an example it would help a lot. I added the verbs to turn EAPD on in the pin configs and it shows up in IOReg but I wonder if it's being passed since it's a new verb and god knows what Apple's driver does with it :)

Looking at the input side, 0xc is definitely the connection in use (it's the default) which would make the nodes like this:

IntSpeakers: 0x02 (2), 0x0c (12), 0x14 (20)
HP Jack: 0x02 (2), 0x0c (12), 0x15 (21)

With the nested pathmap Snickers has that switches 20 & 21 it will use the correct output based on the HP being plugged in.

As far as Azalia, it should be fairly easy to check. AppleAzaliaAudio.kext edits are minor and it works without HDAEnabler. Just remove the 2 HDA kext and install Azalia then we can run through what it is doing. My guess is that it uses the HP jack because that is a default on power up. The unfortuante thing with Azalia is there's not much to edit. If I knew where I could change it from HP to speakers I would make that edit and at least have 1 audio out until this damn AppleHDA is my bitch :D

Last edited on 1224525463|%e %b %Y, %H:%M %Z|agohover By Toonces + Show more

Re: AppleHDA.kext progress

codeye 1224476711|%e %b %Y, %H:%M %Z|agohover

I think you and Snickers have the kexts hacked nicely at this stage but of course no sound. Why? Is it the wrong muteGPIO setting(whatever these are, not really defined in the datasheets)? or something else - seems just eyeballing the EAPD enabled setting isn't being activated (and isn't present on the alc885 or alc262) and in linux toggling this on and off turns the speaker on and off (but not the hp) but cannot manage this yet under osx. I've looked at the datasheet a few times (mind you that was about 2 months ago) and I missed the crucial bit about the extra amps hooked up to nodes 2 + 3, so I probably should start over again. I think linux is using node 0xC from memory (switch on and off with hda-verb).

Re: AppleHDA.kext progress

snickersmd 1224488042|%e %b %Y, %H:%M %Z|agohover

Yay, codeye is back! ;) I'm very excited about your reggie findings. I think they may hold the key. Please document all you find, as at this point, I don't think any other group has had to go so far with the AppleHDA.kext.

MuteGPIO is a strange setting indeed. It's not mentioned directly in either the Intel spec nor the Realtek data sheets. It might be a compound setting that Apple uses to set multiple bit values in the spec. I did some tabulation to unravel the mystery behind these but I don't have time to post my work right now.

Also, with the new kext hacks, why is it that the MuteGPIO settings for the inputs, copied from stock, don't crash the whole setup, while putting them in the outputs does?

Toonces, you've done a lot of fine poking around. A four node widget? Hmmm… Haven't seen it in Realtek and I figured it was unique to Stac. It certainly deserves a look though.

Remember a couple of posts ago, when you were asking about PCI Match values as suggested by MadTux, and I shot it down simply because from what I've read in the IOKit documentation, matching just helps the driver find valid devices and since ours is loading, then we know all the devices have been found and therefore matched… Or have they? I've been doing some more side by side comparison between comatron's Azalia ioreg dump and our current ioreg with the latest kext… the match information is vastly different. Does this have anything to do with our problem? Maybe, maybe not. At this moment, anything goes, yet I find codeye's latest findings most promising.

I'll keep messing with it whenever I find time.

Re: AppleHDA.kext progress

Toonces 1224490011|%e %b %Y, %H:%M %Z|agohover

Ok, I did find that MuteGPIO in the outputs does indeed crash. Hard :)

There are a couple of things I was just trying and I went back to your original codec just now because I made too many changes at once and was crashing. I guess it's the MuteGPIO I added to the output. Where you will find MuteGPIO is in the ALC885. It's a separate circuit and I am thinking we don't have to worry about it. Something that codeye just mentioned makes complete sense to me now. EAPD = External Amp Power Down which is a signal to mute/unmute an external amp. According to the ALC269 datasheet, it does apply to both nodes 14 & 15 which are the speakers and headphones though they would both be required to be set individually which is why maybe in linux turning it off only effects the speakers because that is all you are turning off. Guessing, the key to sound out is control of the EAPD. Somehow we need to inject the codec verb to turn this thing on for both nodes. All the amp moving in the wolrd isn't going to change anything if the amp isn't on :)

I am going to try a few more things. I think I saw someplace we could add a codec verb that maybe we can use to turn the EAPD on as part of the initialization? or maybe post initialization?

For PCIMatch, If you look at AppleHDA from just a few versions ago they were using the PCI address to match things up. I'm not sure it matters right now though as I really think the key is EAPD.

Re: AppleHDA.kext progress

Toonces 1224493145|%e %b %Y, %H:%M %Z|agohover

Well Bummer. I added a verb to turn on EAPD for both the Speakers and HP and it looks like it was accepted as part of the initial config but Still my 1000H remains silent…..

Re: AppleHDA.kext progress

comatron 1224622424|%e %b %Y, %H:%M %Z|agohover

the new macbooks are out and with em some system update (including nforce/nvidia/ati drivers for new hardware). latest AppleHDA.kext there loaded is .5.8 - so was there maybe an update included? i dont know the version-number you guys are workin on ….

Re: AppleHDA.kext progress

codeye 1224664159|%e %b %Y, %H:%M %Z|agohover

comatron,
I tried a quick patch the updated kext last week adding in the byte change from 32 to 33 as per snickers but received new (and no less obfuscating) sound assertion errors so I didn't pursue it.
I will continue to toil away on peeking and poking the codec with verbs on the 269 and 885 to see if i can work out what is wrong - this should eventually work but is time consuming (if you guys can get sound working through the plist please put me out of my misery). I will try to write a small program that automates this but my coding skills are really rusty! One thing which might help though is that in ubuntu with hda-verb you can turn sound on and off on the speakers by adjusting amps on all 3 nodes 0x02 with mute and volume 0xc with mute and 0x14 with mute and EAPD on/off - so all these must be set the correct way to get sound, I've just not had time to check whether we set them with the current plist correctly yet.

Re: AppleHDA.kext progress

Toonces 1224808676|%e %b %Y, %H:%M %Z|agohover

@codeye, If you can give me a quick bit of instruction on what to do with reggie I will help with that. I added the verb to turn on EAPD but that didn't help. I don't have mute controls either anymore (though I did at one point) so maybe it's a mute thing. Nevertheless, it should be possible to pass the entire configuration and turn on of all mute & amps along the way using verbs but I don't know if anything beyond the pin configs are actually working when I add the verbs to the pin config. If you can help me to understand reggie I can check my work as I go.

@Snickers, After reading one of the posts about coolbook, it occurred to me, what if the problem is the latest AppleHDA.kext? Is it possible that an earlier version from 10.5.0/10.5.1 would work where the latest one may not?? Unfortunately I haven't had much time this week to do anything but I wanted to throw that out there since AppleAzalia works at least in part…..

Re: AppleHDA.kext progress

codeye 1224841925|%e %b %Y, %H:%M %Z|agohover

Toonces,
I agree that trying the plist in an earlier version of AppleHDA.kext is a good idea. I've uploaded a program which should allow you to run different codec verbs on different NodeIDs - using the graphical form of Reggie was doing my head in. It requires reggie to be installed (Developer Tools), as well as lspci (to find the IOMemoryAddress) and of course needs admin privileges to access physical memory. I just whipped it up and its pretty basic at present but it should allow you to read and write to the codec - I will use the basic workings to produce an automated codec dump so we can all compare the settings on the ALC269 on our different machines - particularly comatron who has sound working on headphones. the 2 files to download are now on the wiki page, pcutils*.zip and verb_commands2.zip.

Last edited on 1224844946|%e %b %Y, %H:%M %Z|agohover By codeye + Show more

Re: AppleHDA.kext progress

Toonces 1224860014|%e %b %Y, %H:%M %Z|agohover

Codeye, THAT ROCKS! I have all those things installed but just wasn't quite getting what to do to set and read the values. I will download it and get started. I spent a couple of hours last night messing around with mute settings and the current codec or something really does not like unmute. Whether I set it using MuteGPIO=0 on an output or through a codec verb (014380000 for output amp) the results are the same. Bad Things™ I will start working on this as soon as I can with some of the earlier codecs. hopefully I can find a couple of unmolested earlier versions as the plists are different than the one we've been working with. Still layout and pathmap but not quite as evolved.

Re: AppleHDA.kext progress

comatron 1224861017|%e %b %Y, %H:%M %Z|agohover

i spent the last 2 days testing about 30 new kexts from madtux (over on insanely) and sending him results. im sick of rebooting but i wont give that one up - i gotta fight this sh*t. his kexts did show correct sysprof AND correct syspane fields AND volume symbol - for me this was the first time with the hda (cause azalia worked before). i dont know wtf madtux is doin but i guess he´s goin diffenrent ways - which may be good - i dont know.

codeeye, i gonna download the stuff from wiki and try to get reggie (hope i can get it single - like i got the ioreg tool single) and lspci. but my noobishness seems a problem. you guys tell me exactly what to do - i do it all night long and report it :)

Last edited on 1224861036|%e %b %Y, %H:%M %Z|agohover By comatron + Show more

Re: AppleHDA.kext progress

Toonces 1224868574|%e %b %Y, %H:%M %Z|agohover

ok, I am currently running the last AppleHDA.kext that Snickers uploaded on Oct 16th and something is either waaaay off with the pin configs or the Node ID in codeye's program are in something other than Hex. For example, I queried the audio widget capabilities for node 14 which should be speaker out and it comes back with 0x0020010a which translates to:

Mono Wdiget, InAmp Present, OutAmp Not Present, AmpParamter Override, No Processing Control, Unsolicited not supported, Connection list must be queried, Analog, Power Control not supported, Widget Type: MIXER.

This is very very wrong. At the very least the node type should be Audio Output and not Mixer. Other nodes I queried show the same misconfiguration so I am thinking that our pin configs are either not being read or being overridden.

EDIT: Ok, I figured out what the deal is. Codeye's app is taking Node ID and Parameter ID in Decimal values instead of Hex.

@Codeye, could you change the NodeID & ParameterID to use Hex instead of Decimal so it matches what is expected to be input from the data sheet? It's an AWESOME app for looking at what is going on. So far, everything looks to be configured correctly..

EDIT 2: @Codeye, I cannot seem to get the Amp gain (Verb B) as I cannot enter 32768 in Parameter ID so that bit 15 will be set when querying Node 12 (0xC). I was able to turn on EAPD but can't check or set the Mute state in the mixer. Also, I'm not sure if this makes much of a difference but when trying to set a value like 0x02, the leading 0 is automatically removed. I know it shouldn't make a difference as 2 is 2 :). I'm probably pushing it now :D

Last edited on 1224873532|%e %b %Y, %H:%M %Z|agohover By Toonces + Show more

Re: AppleHDA.kext progress

codeye 1224897256|%e %b %Y, %H:%M %Z|agohover

Good to see you guys are interested! Messed up the size of PID I will fix this and let you enter values in hex - just trying to get the codec dump program working. If snickers is watching I cannot delete any of the earlier versions of the program!
I will quickly upload a version that should work for the gain results, still decimal thou and the verb is actually B00 (not 0xB). Latest version is verb_commands0.2.zip - if snickers is watching could he delete the old versions. I'll try and get the codec dump out today and then clean up the verb program.

Last edited on 1224897579|%e %b %Y, %H:%M %Z|agohover By codeye + Show more

Re: AppleHDA.kext progress

comatron 1224901346|%e %b %Y, %H:%M %Z|agohover

guys! madtux sent me a kext, which is acting STRANGE. try it here:

http://www.mediafire.com/?sharekey=0d7f0c4797378ca4d2db6fb9a8902bda

what it does here:

when i put headphones in headphones jack - THIS happens:

the only output i have n syspane (speakers) switches to HEADPHONES and does change the volume. both have working faders! also the the mic ins (both) start to act strange and show input data flushing (input level goin up and down)

this time (and i had kexts from madtux before, where both jacks gave me power - in form of crackles when put/pull/put/pull the cable) i only hear crackle when pull/put/pull/put the cable in the headphones jack. the mic jack - which has crackeled in other versions does NOT crackle anymore. seems like theres no more power on this mic jack.

i hope this will help. this feels like a breakthru for me as i had never workin faders or any notcable reactions when putting a cable.

Re: AppleHDA.kext progress

Toonces 1224907352|%e %b %Y, %H:%M %Z|agohover

Thanks for posting that comatron! Snicker's kext actually does the same thing for me as you describe but it will be nice to compare what MadTux has to see what version of the codec he's using and what differences he might have. I'll give it a spin with Codeye's program and see what differences there are when it's running too.

Re: AppleHDA.kext progress

Toonces 1224907226|%e %b %Y, %H:%M %Z|agohover

Thanks Codeye! I will download and try the latest versions. According to the ALC269 datasheet the verb is 0xB and the verb is only 4 bits long (bits19:16). B00 would put it into the payload bits of which, bit 15 needs to be set in order to get output gain values instead of input gain values. It's on page 38 of the datasheet. There are a few verbs that are only 4 bits wide according to that datasheet and they all have 16 bit payload bits. So with that said, is your program always expecting 12 bits for verb? I could work with that and send appropriately if I know.

Re: AppleHDA.kext progress

codeye 1224903506|%e %b %Y, %H:%M %Z|agohover

I'll have to try it out - sounds like we (well at least madtux) are getting there.
I've uploaded another version of the verb commands this one uses hex input!

Re: AppleHDA.kext progress

codeye 1224911166|%e %b %Y, %H:%M %Z|agohover

Works the same as the hda-verb prog on linux, so any 4 bit verbs need to have 00 added to the end. if you open up the reggie_se graphical program and look at the physical memory for the codec (given in Ioregexplorer and lspci -v) 0x60 is where the verb is set and 0x64 is the response.

Re: AppleHDA.kext progress

codeye 1224956992|%e %b %Y, %H:%M %Z|agohover

OK. I have bashed out a program codec_dump which should produce most of the info available on /proc/asound/codec/codec#0 under linux. It takes eons to run (about 3 min) during which time it is unresponsive.
I am most interested in how comatrons codec is set up with azalia accessing (successfully) the hp nodes. But all insights are welcome. It sounds like Madtux's kext may also be turning on the appropriate amps so the results from that appleHDA.kext would also be useful. The program should work on other realtek codecs (provided they use codec address 0) so the results of working sound systems would also be interesting. File uploaded to wiki codec_dump0.1

Re: AppleHDA.kext progress

Toonces 1224981043|%e %b %Y, %H:%M %Z|agohover

Here's a dump from my 1000H running Snicker's AppleHDA. It looks like all it needs is EAPD turned on and the output nodes unmuted. The problem that I've had is that every time I set an output node to unmute OS X crashes hard. turning EAPD is safe though :) I'll give the kext that comatron uploaded and see what I get. I'll give AppleAzalia a try too to see what is going on there too.

Vendor Id: 0x10ec0269
Revision Id: 0x00100004
Node 0x2 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out
Amp-Out caps: ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x00 0x00]
Converter: stream=1, channel=0
Node 0x3 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out
Amp-Out caps: ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x00 0x00]
Converter: stream=0, channel=0
Node 0x4 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Node 0x5 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Node 0x6 [Audio Output] wcaps 0x00000211: Stereo Digital
Converter: stream=0, channel=0
Node 0x7 [Audio Input] wcaps 0x0010011b: Stereo Amp-In
Amp-In caps: ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1
Amp-In vals: [0x17 0x17]
Converter: stream=0, channel=0
Connection: 1
Node 0x8 [Audio Input] wcaps 0x0010011b: Stereo Amp-In
Amp-In caps: ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1
Amp-In vals: [0x1a 0x1a]
Converter: stream=0, channel=0
Connection: 1
Node 0x9 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 1
Node 0xA [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 1
Node 0xB [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
Amp-In vals: [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97]
Connection: 5
Node 0xC [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x80 0x80]
Connection: 2
Node 0xD [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x80 0x80]
Connection: 2
Node 0xE [Audio Mixer] wcaps 0x0020010a: Mono Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x80 0x80]
Connection: 2
Node 0xF [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x10 [Audio Output] wcaps 0x00000211: Stereo Digital
Converter: stream=0, channel=0
Connection: 2
Node 0x11 [Pin Complex] wcaps 0x00400380: Mono Digital
Pincap 0x00000014: OUT Detect
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x12 [Pin Complex] wcaps 0x00400001: Stereo
Pincap 0x00000020: IN
Pin Default 0x99a30920: [Fixed] Mic In at Int ATAPI
Conn = ATAPI , Colour = Unknown
DefAssociation = 0x2, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN VREF_HIZ
Connection: 2
Node 0x13 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x14 [Pin Complex] wcaps 0x0040010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x00010050: OUT Balanced
Pin Default 0x99130110: [Fixed] Speaker at Int ATAPI
Conn = ATAPI , Colour = Unknown
DefAssociation = 0x1, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Connection: 2
Node 0x15 [Pin Complex] wcaps 0x0040018d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x0001001c: OUT HP Detect
Pin Default 0x0121401f: [Jack] HP Out at Ext Rear
Conn = 1/8 , Colour = Green
DefAssociation = 0x1, Sequence = 0xF
Pin-ctls: 0xc0: OUT HP VREF_HIZ
Unsolicited: tag=3, enabled=1
Connection: 2
Node 0x16 [Pin Complex] wcaps 0x0040010c: Mono Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x00000010: OUT
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Connection: 2
Node 0x17 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x18 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x03 0x03] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00003734: IN OUT EAPD Detect
EAPD 0x0:
Pin Default 0x01a19830: [Jack] Mic In at Ext Rear
Conn = 1/8 , Colour = Pink
DefAssociation = 0x3, Sequence = 0x0
Pin-ctls: 0x22: IN GROUND
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x19 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00003734: IN OUT EAPD Detect
EAPD 0x0:
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1A [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x0000373c: IN OUT HP EAPD Detect
EAPD 0x0:
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1B [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00003734: IN OUT EAPD Detect
EAPD 0x0:
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1C [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x1D [Pin Complex] wcaps 0x00400000: Mono
Pincap 0x00000020: IN
Pin Default 0x4005822d: [N/A] Line Out at Ext N/A
Conn = Optical , Colour = Purple
DefAssociation = 0x2, Sequence = 0xD
Pin-ctls: 0x00: VREF_HIZ
Connection: 2
Node 0x1E [Pin Complex] wcaps 0x00400380: Mono Digital
Pincap 0x00000014: OUT Detect
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1F [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x20 [Vendor Defined Widget] wcaps 0x00f00040: Mono
Connection: 2
Node 0x21 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x22 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x23 [Audio Selector] wcaps 0x00300101: Stereo
Connection: 2

Re: AppleHDA.kext progress

Toonces 1224982707|%e %b %Y, %H:%M %Z|agohover

and here's a dump using the AppleHDA from MadTux. MadTux's is based on an earlier codec (1.3.3 vs 1.5.7). I don't see any differences in the dumps and the amps are muted in this one as well. Neither one shows mute control in the audio prefpane either.

Vendor Id: 0x10ec0269
Revision Id: 0x00100004
Node 0x2 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out
Amp-Out caps: ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x00 0x00]
Converter: stream=1, channel=0
Node 0x3 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out
Amp-Out caps: ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x00 0x00]
Converter: stream=0, channel=0
Node 0x4 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Node 0x5 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Node 0x6 [Audio Output] wcaps 0x00000211: Stereo Digital
Converter: stream=0, channel=0
Node 0x7 [Audio Input] wcaps 0x0010011b: Stereo Amp-In
Amp-In caps: ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1
Amp-In vals: [0x17 0x17]
Converter: stream=1, channel=0
Connection: 1
Node 0x8 [Audio Input] wcaps 0x0010011b: Stereo Amp-In
Amp-In caps: ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1
Amp-In vals: [0x1a 0x1a]
Converter: stream=2, channel=0
Connection: 1
Node 0x9 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 1
Node 0xA [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 1
Node 0xB [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
Amp-In vals: [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97]
Connection: 5
Node 0xC [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x80 0x80]
Connection: 2
Node 0xD [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x80 0x80]
Connection: 2
Node 0xE [Audio Mixer] wcaps 0x0020010a: Mono Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x80 0x80]
Connection: 2
Node 0xF [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x10 [Audio Output] wcaps 0x00000211: Stereo Digital
Converter: stream=0, channel=0
Connection: 2
Node 0x11 [Pin Complex] wcaps 0x00400380: Mono Digital
Pincap 0x00000014: OUT Detect
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x12 [Pin Complex] wcaps 0x00400001: Stereo
Pincap 0x00000020: IN
Pin Default 0x99a30910: [Fixed] Mic In at Int ATAPI
Conn = ATAPI , Colour = Unknown
DefAssociation = 0x1, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN VREF_HIZ
Connection: 2
Node 0x13 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x14 [Pin Complex] wcaps 0x0040010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x00010050: OUT Balanced
Pin Default 0x99130120: [Fixed] Speaker at Int ATAPI
Conn = ATAPI , Colour = Unknown
DefAssociation = 0x2, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Connection: 2
Node 0x15 [Pin Complex] wcaps 0x0040018d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x0001001c: OUT HP Detect
Pin Default 0x01214030: [Jack] HP Out at Ext Rear
Conn = 1/8 , Colour = Green
DefAssociation = 0x3, Sequence = 0x0
Pin-ctls: 0xc0: OUT HP VREF_HIZ
Unsolicited: tag=3, enabled=1
Connection: 2
Node 0x16 [Pin Complex] wcaps 0x0040010c: Mono Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x00000010: OUT
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Connection: 2
Node 0x17 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x18 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x03 0x03] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00003734: IN OUT EAPD Detect
EAPD 0x0:
Pin Default 0x01a19840: [Jack] Mic In at Ext Rear
Conn = 1/8 , Colour = Pink
DefAssociation = 0x4, Sequence = 0x0
Pin-ctls: 0x20: IN VREF_HIZ
Unsolicited: tag=8, enabled=0
Connection: 2
Node 0x19 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x80 0x80]
Pincap 0x00003734: IN OUT EAPD Detect
EAPD 0x0:
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1A [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x80 0x80]
Pincap 0x0000373c: IN OUT HP EAPD Detect
EAPD 0x0:
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1B [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x80 0x80]
Pincap 0x00003734: IN OUT EAPD Detect
EAPD 0x0:
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1C [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x1D [Pin Complex] wcaps 0x00400000: Mono
Pincap 0x00000020: IN
Pin Default 0x40058250: [N/A] Line Out at Ext N/A
Conn = Optical , Colour = Purple
DefAssociation = 0x5, Sequence = 0x0
Pin-ctls: 0x00: VREF_HIZ
Connection: 2
Node 0x1E [Pin Complex] wcaps 0x00400380: Mono Digital
Pincap 0x00000014: OUT Detect
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1F [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x20 [Vendor Defined Widget] wcaps 0x00f00040: Mono
Connection: 2
Node 0x21 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x22 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x23 [Audio Selector] wcaps 0x00300101: Stereo
Connection: 2

Re: AppleHDA.kext progress

hagglebeef 1224984445|%e %b %Y, %H:%M %Z|agohover

Hi everyone - I have been following the posts and want to jump in and say that I have sound working from speaker using the AppleAzalia.kext. I used a strange method to get it to work, but it is repeatable, after two reboots. I am including what the dump from the working AppleAzalia.kext:

Vendor Id: 0x10ec0269
Revision Id: 0x00100004
Node 0x2 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out
Amp-Out caps: ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x00 0x00]
Converter: stream=1, channel=0
Node 0x3 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out
Amp-Out caps: ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x00 0x00]
Converter: stream=0, channel=0
Node 0x4 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Node 0x5 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Node 0x6 [Audio Output] wcaps 0x00000211: Stereo Digital
Converter: stream=0, channel=0
Node 0x7 [Audio Input] wcaps 0x0010011b: Stereo Amp-In
Amp-In caps: ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1
Amp-In vals: [0x00 0x00]
Converter: stream=0, channel=0
Connection: 1
Node 0x8 [Audio Input] wcaps 0x0010011b: Stereo Amp-In
Amp-In caps: ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1
Amp-In vals: [0x90 0x90]
Converter: stream=0, channel=0
Connection: 1
Node 0x9 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 1
Node 0xA [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 1
Node 0xB [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
Connection: 5
Node 0xC [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x80 0x80]
Connection: 2
Node 0xD [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x00 0x00]
Connection: 2
Node 0xE [Audio Mixer] wcaps 0x0020010a: Mono Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x00 0x00]
Connection: 2
Node 0xF [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x10 [Audio Output] wcaps 0x00000211: Stereo Digital
Converter: stream=0, channel=0
Connection: 2
Node 0x11 [Pin Complex] wcaps 0x00400380: Mono Digital
Pincap 0x00000014: OUT Detect
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x12 [Pin Complex] wcaps 0x00400001: Stereo
Pincap 0x00000020: IN
Pin Default 0x99a30920: [Fixed] Mic In at Int ATAPI
Conn = ATAPI , Colour = Unknown
DefAssociation = 0x2, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN VREF_HIZ
Connection: 2
Node 0x13 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x14 [Pin Complex] wcaps 0x0040010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x00010050: OUT Balanced
Pin Default 0x99130110: [Fixed] Speaker at Int ATAPI
Conn = ATAPI , Colour = Unknown
DefAssociation = 0x1, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Connection: 2
Node 0x15 [Pin Complex] wcaps 0x0040018d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x0001001c: OUT HP Detect
Pin Default 0x0121401f: [Jack] HP Out at Ext Rear
Conn = 1/8 , Colour = Green
DefAssociation = 0x1, Sequence = 0xF
Pin-ctls: 0xc0: OUT HP VREF_HIZ
Unsolicited: tag=4, enabled=1
Connection: 2
Node 0x16 [Pin Complex] wcaps 0x0040010c: Mono Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x00000010: OUT
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Connection: 2
Node 0x17 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x18 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x80 0x80]
Pincap 0x00003734: IN OUT EAPD Detect
EAPD 0x0:
Pin Default 0x01a19830: [Jack] Mic In at Ext Rear
Conn = 1/8 , Colour = Pink
DefAssociation = 0x3, Sequence = 0x0
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x19 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00003734: IN OUT EAPD Detect
EAPD 0x0:
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x44: OUT VREF_80
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1A [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x0000373c: IN OUT HP EAPD Detect
EAPD 0x0:
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1B [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00003734: IN OUT EAPD Detect
EAPD 0x0:
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1C [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x1D [Pin Complex] wcaps 0x00400000: Mono
Pincap 0x00000020: IN
Pin Default 0x4005822d: [N/A] Line Out at Ext N/A
Conn = Optical , Colour = Purple
DefAssociation = 0x2, Sequence = 0xD
Pin-ctls: 0x00: VREF_HIZ
Connection: 2
Node 0x1E [Pin Complex] wcaps 0x00400380: Mono Digital
Pincap 0x00000014: OUT Detect
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1F [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x20 [Vendor Defined Widget] wcaps 0x00f00040: Mono
Connection: 2
Node 0x21 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x22 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x23 [Audio Selector] wcaps 0x00300101: Stereo
Connection: 2

Let me know if you guys need additional information.

Last edited on 1224984888|%e %b %Y, %H:%M %Z|agohover By hagglebeef + Show more

Re: AppleHDA.kext progress

codeye 1224990004|%e %b %Y, %H:%M %Z|agohover

Hagglebeef,
thanks for chipping in! Could you explain how you have managed to get azalia up and running, if I can do the same then I can tinker with the nodes to see whats happening at the codec level. I hope (but I'm not sure) that a combination of looking at the codec setup and the correct plist will get us there. I've uploaded a revised codec dump program as the first one unfortunately mucked up the EAPD positioning - sorry guys. Ive also added an updated codec verb program which will display all the node settings under the affected node which will speed things up. Two new files in the wiki verb_command_plus0.1.zip and codec_dump0.2.zip.

Re: AppleHDA.kext progress

hagglebeef 1225030964|%e %b %Y, %H:%M %Z|agohover

Codeye,

I took another dump of the working AppleAzalia codec using your revised codec dump program. Hope this helps:

Vendor Id: 0x10ec0269
Revision Id: 0x00100004
Node 0x2 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out
Amp-Out caps: ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x00 0x00]
Converter: stream=1, channel=0
Node 0x3 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out
Amp-Out caps: ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x00 0x00]
Converter: stream=0, channel=0
Node 0x4 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Node 0x5 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Node 0x6 [Audio Output] wcaps 0x00000211: Stereo Digital
Converter: stream=0, channel=0
Node 0x7 [Audio Input] wcaps 0x0010011b: Stereo Amp-In
Amp-In caps: ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1
Amp-In vals: [0x00 0x00]
Converter: stream=0, channel=0
Connection: 1
Node 0x8 [Audio Input] wcaps 0x0010011b: Stereo Amp-In
Amp-In caps: ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1
Amp-In vals: [0x90 0x90]
Converter: stream=0, channel=0
Connection: 1
Node 0x9 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 1
Node 0xA [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 1
Node 0xB [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
Connection: 5
Node 0xC [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x80 0x80]
Connection: 2
Node 0xD [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x00 0x00]
Connection: 2
Node 0xE [Audio Mixer] wcaps 0x0020010a: Mono Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x00 0x00]
Connection: 2
Node 0xF [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x10 [Audio Output] wcaps 0x00000211: Stereo Digital
Converter: stream=0, channel=0
Connection: 2
Node 0x11 [Pin Complex] wcaps 0x00400380: Mono Digital
Pincap 0x00000014: OUT Detect
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x12 [Pin Complex] wcaps 0x00400001: Stereo
Pincap 0x00000020: IN
Pin Default 0x99a30920: [Fixed] Mic In at Int ATAPI
Conn = ATAPI , Colour = Unknown
DefAssociation = 0x2, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN VREF_HIZ
Connection: 2
Node 0x13 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x14 [Pin Complex] wcaps 0x0040010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x00010050: OUT EAPD Balanced
EAPD 0x2:EAPD
Pin Default 0x99130110: [Fixed] Speaker at Int ATAPI
Conn = ATAPI , Colour = Unknown
DefAssociation = 0x1, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Connection: 2
Node 0x15 [Pin Complex] wcaps 0x0040018d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x0001001c: OUT HP EAPD Detect
EAPD 0x2:EAPD
Pin Default 0x0121401f: [Jack] HP Out at Ext Rear
Conn = 1/8 , Colour = Green
DefAssociation = 0x1, Sequence = 0xF
Pin-ctls: 0xc0: OUT HP VREF_HIZ
Unsolicited: tag=4, enabled=1
Connection: 2
Node 0x16 [Pin Complex] wcaps 0x0040010c: Mono Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x00000010: OUT
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Connection: 2
Node 0x17 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x18 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x80 0x80]
Pincap 0x00003734: IN OUT Detect
Pin Default 0x01a19830: [Jack] Mic In at Ext Rear
Conn = 1/8 , Colour = Pink
DefAssociation = 0x3, Sequence = 0x0
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x19 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00003734: IN OUT Detect
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x44: OUT VREF_80
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1A [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x0000373c: IN OUT HP Detect
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1B [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00003734: IN OUT Detect
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1C [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x1D [Pin Complex] wcaps 0x00400000: Mono
Pincap 0x00000020: IN
Pin Default 0x4005822d: [N/A] Line Out at Ext N/A
Conn = Optical , Colour = Purple
DefAssociation = 0x2, Sequence = 0xD
Pin-ctls: 0x00: VREF_HIZ
Connection: 2
Node 0x1E [Pin Complex] wcaps 0x00400380: Mono Digital
Pincap 0x00000014: OUT Detect
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8 , Colour = Black
DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0
Connection: 2
Node 0x1F [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x20 [Vendor Defined Widget] wcaps 0x00f00040: Mono
Connection: 2
Node 0x21 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x22 [Vendor Defined Widget] wcaps 0x00f00000: Mono
Connection: 2
Node 0x23 [Audio Selector] wcaps 0x00300101: Stereo
Connection: 2

Re: AppleHDA.kext progress

Toonces 1224990254|%e %b %Y, %H:%M %Z|agohover

Hi Hagglebeef, Excellent! Can you upload the AppleAzaliaAudio.kext and what you had to do to get it working with speakers? If you can't upload it here, please upload it somewhere like mediafire or rapidshare so we can take a look at what it's doing differently.

Re: AppleHDA.kext progress

hagglebeef 1224991802|%e %b %Y, %H:%M %Z|agohover

Codeye,

I am using the retail method to boot into OSX on a eee901. After setting everything up, I had the same problem as everyone else and could not get sound to work. I abandon OSX for awhile and put Ubuntu on a 16GB SD card and started looking at the alsa code to see what made it work. Like all of you I got frustrated at looking at the codec dumps and finally downloaded the alsa sound driver code and recompiled it with some debugging info at the read and write codec so I could see how it was setting things up. At the same time, I just got an Acer AspireOne from BB and started to do the samething on the ALC268 which already had a modify AppleHDA.kext. After looking at the pin config on the ALC268 AppleHDA.kext, I notice it was not default pin verbs that was in it, but a complete setup_preset from the Linux alsa realtek driver. So, I replace the ALC268 verbs for ALC269 verbs, but nothing happen. At that time, I notice on this discussion that comatron had sound working using the AppleAzalia.kext so I download audio_kexts_eeepc.zip and installed it and suddenly had sounds from internal speaker, but would lose it when it goes to sleep or reboots. To get it back, I would have to remove the AppleAzalia.kext and reinstall the AppleHDA.kext with the new verbs reboot and then re-install AppleAzalia.kext reboot again and internal speaker sound would appear again.

Here is the listing of the verbs that got dumped from Ubuntu:

[   56.369545] hda_codec: snd_hda_codec_read verbs 000 0 f00 0 = 10ec0269
[   56.369602] hda_codec: snd_hda_codec_read verbs 000 0 f00 1 = 0
[   56.369664] hda_codec: snd_hda_codec_read verbs 000 0 f00 2 = 100004
[   56.369724] hda_codec: snd_hda_codec_read verbs 000 0 f00 4 = 10001
[   56.369801] hda_codec: snd_hda_codec_read verbs 001 0 f00 5 = 101
[   56.369851] hda_codec: snd_hda_codec_read verbs 001 0 f00 4 = 20023
[   56.369912] hda_codec: snd_hda_codec_read verbs 002 0 f00 9 = 1d
[   56.369973] hda_codec: snd_hda_codec_read verbs 003 0 f00 9 = 1d
[   56.370014] hda_codec: snd_hda_codec_read verbs 004 0 f00 9 = f00000
[   56.370056] hda_codec: snd_hda_codec_read verbs 005 0 f00 9 = f00000
[   56.370098] hda_codec: snd_hda_codec_read verbs 006 0 f00 9 = 211
[   56.370140] hda_codec: snd_hda_codec_read verbs 007 0 f00 9 = 10011b
[   56.370181] hda_codec: snd_hda_codec_read verbs 008 0 f00 9 = 10011b
[   56.370222] hda_codec: snd_hda_codec_read verbs 009 0 f00 9 = f00000
[   56.370264] hda_codec: snd_hda_codec_read verbs 00a 0 f00 9 = f00000
[   56.370305] hda_codec: snd_hda_codec_read verbs 00b 0 f00 9 = 20010b
[   56.370347] hda_codec: snd_hda_codec_read verbs 00c 0 f00 9 = 20010b
[   56.370389] hda_codec: snd_hda_codec_read verbs 00d 0 f00 9 = 20010b
[   56.370431] hda_codec: snd_hda_codec_read verbs 00e 0 f00 9 = 20010a
[   56.370473] hda_codec: snd_hda_codec_read verbs 00f 0 f00 9 = f00000
[   56.370514] hda_codec: snd_hda_codec_read verbs 010 0 f00 9 = 211
[   56.370555] hda_codec: snd_hda_codec_read verbs 011 0 f00 9 = 400380
[   56.370596] hda_codec: snd_hda_codec_read verbs 012 0 f00 9 = 400001
[   56.370639] hda_codec: snd_hda_codec_read verbs 013 0 f00 9 = f00000
[   56.370701] hda_codec: snd_hda_codec_read verbs 014 0 f00 9 = 40010d
[   56.370743] hda_codec: snd_hda_codec_read verbs 015 0 f00 9 = 40018d
[   56.370785] hda_codec: snd_hda_codec_read verbs 016 0 f00 9 = 40010c
[   56.370826] hda_codec: snd_hda_codec_read verbs 017 0 f00 9 = f00000
[   56.370867] hda_codec: snd_hda_codec_read verbs 018 0 f00 9 = 40018f
[   56.370909] hda_codec: snd_hda_codec_read verbs 019 0 f00 9 = 40018f
[   56.370950] hda_codec: snd_hda_codec_read verbs 01a 0 f00 9 = 40018f
[   56.370992] hda_codec: snd_hda_codec_read verbs 01b 0 f00 9 = 40018f
[   56.371034] hda_codec: snd_hda_codec_read verbs 01c 0 f00 9 = f00000
[   56.371076] hda_codec: snd_hda_codec_read verbs 01d 0 f00 9 = 400000
[   56.371117] hda_codec: snd_hda_codec_read verbs 01e 0 f00 9 = 400380
[   56.371158] hda_codec: snd_hda_codec_read verbs 01f 0 f00 9 = f00000
[   56.371200] hda_codec: snd_hda_codec_read verbs 020 0 f00 9 = f00040
[   56.371242] hda_codec: snd_hda_codec_read verbs 021 0 f00 9 = f00000
[   56.371283] hda_codec: snd_hda_codec_read verbs 022 0 f00 9 = f00000
[   56.371325] hda_codec: snd_hda_codec_read verbs 023 0 f00 9 = 300101
[   56.371367] hda_codec: snd_hda_codec_read verbs 024 0 f00 9 = 20010b
[   56.371408] hda_codec: snd_hda_codec_read verbs 001 0 f20 0 = 1043831a
[   56.371421] hda_codec: snd_hda_codec_write verbs 020 0 500 4 = 0
[   56.371492] hda_codec: snd_hda_codec_read verbs 020 0 c00 0 = 8849
[   56.371500] hda_codec: snd_hda_codec_write verbs 020 0 500 4 = 0
[   56.371509] hda_codec: snd_hda_codec_write verbs 020 0 400 849 = 0
[   56.371515] hda_codec: Unknown model for ALC269, trying auto-probe from BIOS...
[   56.371521] hda_codec: custom ALC269, setting ALC269_AUTO...
[   56.371574] hda_codec: snd_hda_codec_read verbs 011 0 f1c 0 = 411111f0
[   56.371616] hda_codec: snd_hda_codec_read verbs 012 0 f1c 0 = 99a30920
[   56.371658] hda_codec: snd_hda_codec_read verbs 014 0 f1c 0 = 99130110
[   56.371720] hda_codec: snd_hda_codec_read verbs 015 0 f1c 0 = 121401f
[   56.371762] hda_codec: snd_hda_codec_read verbs 016 0 f1c 0 = 411111f0
[   56.371804] hda_codec: snd_hda_codec_read verbs 018 0 f1c 0 = 1a19830
[   56.371845] hda_codec: snd_hda_codec_read verbs 019 0 f1c 0 = 411111f0
[   56.371886] hda_codec: snd_hda_codec_read verbs 01a 0 f1c 0 = 411111f0
[   56.371928] hda_codec: snd_hda_codec_read verbs 01b 0 f1c 0 = 411111f0
[   56.371970] hda_codec: snd_hda_codec_read verbs 01e 0 f1c 0 = 411111f0
[   56.371977] ALSA /usr/src/alsa/alsa-driver-1.0.17/pci/hda/hda_codec.c:3062: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0)
[   56.371988] ALSA /usr/src/alsa/alsa-driver-1.0.17/pci/hda/hda_codec.c:3066:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   56.371999] ALSA /usr/src/alsa/alsa-driver-1.0.17/pci/hda/hda_codec.c:3070:    hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
[   56.372009] ALSA /usr/src/alsa/alsa-driver-1.0.17/pci/hda/hda_codec.c:3071:    mono: mono_out=0x0
[   56.372017] ALSA /usr/src/alsa/alsa-driver-1.0.17/pci/hda/hda_codec.c:3079:    inputs: mic=0x12, fmic=0x18, line=0x0, fline=0x0, cd=0x0, aux=0x0
[   56.372029] hda_codec: line_out_pins 14
[   56.372044] hda_codec: hp_pins 15
[   56.372304] hda_codec: snd_hda_codec_read verbs 002 0 f00 a = e0560
[   56.372365] hda_codec: snd_hda_codec_read verbs 002 0 f00 b = 1
[   56.372406] hda_codec: snd_hda_codec_read verbs 007 0 f00 a = e0160
[   56.372448] hda_codec: snd_hda_codec_read verbs 007 0 f00 b = 1
[   56.372653] hda_codec: snd_hda_codec_write verbs 001 0 705 0 = 0
[   56.401410] hda_codec: snd_hda_codec_read verbs 001 0 f05 0 = 400
[   56.409418] hda_codec: snd_hda_codec_read verbs 001 0 f05 0 = 0
[   56.409430] hda_codec: snd_hda_codec_write verbs 020 0 500 4 = 0
[   56.409494] hda_codec: snd_hda_codec_read verbs 020 0 c00 0 = 849
[   56.409502] hda_codec: snd_hda_codec_write verbs 020 0 500 4 = 0
[   56.409511] hda_codec: snd_hda_codec_write verbs 020 0 400 849 = 0
[   56.409520] hda_codec: snd_hda_codec_write verbs 007 0 300 7000 = 0
[   56.409528] hda_codec: snd_hda_codec_write verbs 00b 0 300 7080 = 0
[   56.409544] hda_codec: snd_hda_codec_write verbs 00b 0 300 7180 = 0
[   56.409558] hda_codec: snd_hda_codec_write verbs 00b 0 300 7280 = 0
[   56.409567] hda_codec: snd_hda_codec_write verbs 00b 0 300 7380 = 0
[   56.409581] hda_codec: snd_hda_codec_write verbs 00b 0 300 7480 = 0
[   56.409589] hda_codec: snd_hda_codec_write verbs 002 0 300 b000 = 0
[   56.409604] hda_codec: snd_hda_codec_write verbs 003 0 300 b000 = 0
[   56.409612] hda_codec: snd_hda_codec_write verbs 00c 0 300 7000 = 0
[   56.409627] hda_codec: snd_hda_codec_write verbs 00c 0 300 7100 = 0
[   56.409641] hda_codec: snd_hda_codec_write verbs 00d 0 300 7000 = 0
[   56.409649] hda_codec: snd_hda_codec_write verbs 00d 0 300 7100 = 0
[   56.409664] hda_codec: snd_hda_codec_write verbs 00e 0 300 7000 = 0
[   56.409672] hda_codec: snd_hda_codec_write verbs 00e 0 300 7100 = 0
[   56.409686] hda_codec: snd_hda_codec_write verbs 014 0 707 40 = 0
[   56.409695] hda_codec: snd_hda_codec_write verbs 015 0 707 c0 = 0
[   56.409709] hda_codec: snd_hda_codec_write verbs 016 0 707 40 = 0
[   56.409724] hda_codec: snd_hda_codec_write verbs 018 0 707 24 = 0
[   56.409732] hda_codec: snd_hda_codec_write verbs 019 0 707 24 = 0
[   56.409747] hda_codec: snd_hda_codec_write verbs 01a 0 707 20 = 0
[   56.409755] hda_codec: snd_hda_codec_write verbs 01b 0 707 20 = 0
[   56.409769] hda_codec: snd_hda_codec_write verbs 014 0 300 b000 = 0
[   56.409778] hda_codec: snd_hda_codec_write verbs 015 0 300 b000 = 0
[   56.409792] hda_codec: snd_hda_codec_write verbs 016 0 300 b080 = 0
[   56.409807] hda_codec: snd_hda_codec_write verbs 018 0 300 b080 = 0
[   56.409815] hda_codec: snd_hda_codec_write verbs 019 0 300 b080 = 0
[   56.409830] hda_codec: snd_hda_codec_write verbs 01a 0 300 b080 = 0
[   56.409838] hda_codec: snd_hda_codec_write verbs 01b 0 300 b080 = 0
[   56.409853] hda_codec: snd_hda_codec_write verbs 014 0 701 0 = 0
[   56.409861] hda_codec: snd_hda_codec_write verbs 015 0 701 0 = 0
[   56.409875] hda_codec: snd_hda_codec_write verbs 024 0 300 7000 = 0
[   56.409890] hda_codec: snd_hda_codec_write verbs 024 0 300 7180 = 0
[   56.409898] hda_codec: snd_hda_codec_write verbs 024 0 300 7280 = 0
[   56.409913] hda_codec: snd_hda_codec_write verbs 024 0 300 7380 = 0
[   56.409921] hda_codec: snd_hda_codec_write verbs 014 0 70c 2 = 0
[   56.409935] hda_codec: snd_hda_codec_write verbs 015 0 70c 2 = 0
[   56.410327] hda_codec: snd_hda_codec_read verbs 01d 0 f1c 0 = 4005822d
[   56.410336] hda_codec: snd_hda_codec_write verbs 014 0 70c 2 = 0
[   56.410344] hda_codec: snd_hda_codec_write verbs 015 0 70c 2 = 0
[   56.410352] hda_codec: snd_hda_codec_write verbs 015 0 708 84 = 0
[   56.410361] hda_codec: snd_hda_codec_write verbs 014 0 707 40 = 0
[   56.410375] hda_codec: snd_hda_codec_write verbs 014 0 300 b000 = 0
[   56.410390] hda_codec: snd_hda_codec_write verbs 014 0 701 0 = 0
[   56.410398] hda_codec: snd_hda_codec_write verbs 015 0 707 c0 = 0
[   56.410413] hda_codec: snd_hda_codec_write verbs 015 0 300 b000 = 0
[   56.410421] hda_codec: snd_hda_codec_write verbs 015 0 701 0 = 0
[   56.410435] hda_codec: snd_hda_codec_write verbs 014 0 707 40 = 0
[   56.410444] hda_codec: snd_hda_codec_write verbs 014 0 300 b000 = 0
[   56.410458] hda_codec: snd_hda_codec_write verbs 014 0 701 0 = 0
[   56.410617] hda_codec: snd_hda_codec_read verbs 012 0 f00 c = 20
[   56.410626] hda_codec: snd_hda_codec_write verbs 012 0 707 20 = 0
[   56.410680] hda_codec: snd_hda_codec_read verbs 018 0 f00 c = 3734
[   56.410688] hda_codec: snd_hda_codec_write verbs 018 0 707 24 = 0
[   56.410696] hda_codec: snd_hda_codec_write verbs 018 0 300 b080 = 0
[   56.410765] hda_codec: snd_hda_codec_read verbs 015 0 709 0 = 0
[   56.410826] hda_codec: snd_hda_codec_read verbs 015 0 f09 0 = 0
[   56.410834] hda_codec: snd_hda_codec_write verbs 014 0 707 40 = 0
[   56.410871] hda_codec: snd_hda_set_vmaster_tlv
[   56.410931] hda_codec: snd_hda_codec_read verbs 001 0 f00 12 = 0
[   56.411452] hda_codec: snd_hda_codec_read verbs 014 0 b00 a000 = 0
[   56.411513] hda_codec: snd_hda_codec_read verbs 014 0 b00 8000 = 0
[   56.411575] hda_codec: snd_hda_codec_read verbs 002 0 f00 12 = 3403f
[   56.411636] hda_codec: snd_hda_codec_read verbs 002 0 b00 a000 = 0
[   56.411678] hda_codec: snd_hda_codec_read verbs 002 0 b00 8000 = 0
[   56.411929] hda_codec: snd_hda_codec_read verbs 007 0 f00 d = 80032e11
[   62.540827] hda_codec: snd_hda_mixer_amp_tlv
[   62.540865] hda_codec: snd_hda_mixer_amp_volume_put
[   62.540871] hda_codec: hda_codec_amp_update
[   62.540876] hda_codec: put_vol_mute
[   62.540886] hda_codec: snd_hda_codec_write verbs 002 0 300 a03c = 0
[   62.540891] hda_codec: hda_codec_amp_update
[   62.540895] hda_codec: put_vol_mute
[   62.540903] hda_codec: snd_hda_codec_write verbs 002 0 300 903c = 0
[   62.541004] hda_codec: snd_hda_codec_read verbs 015 0 b00 a000 = 0
[   62.541066] hda_codec: snd_hda_codec_read verbs 015 0 b00 8000 = 0
[   62.541129] hda_codec: snd_hda_codec_read verbs 00b 0 f00 d = 80051f17
[   62.541173] hda_codec: snd_hda_mixer_amp_tlv
[   62.541186] hda_codec: snd_hda_mixer_amp_volume_put
[   62.541191] hda_codec: hda_codec_amp_update
[   62.541233] hda_codec: snd_hda_codec_read verbs 00b 0 b00 2000 = 80
[   62.541238] hda_codec: hda_codec_amp_update
[   62.541296] hda_codec: snd_hda_codec_read verbs 00b 0 b00 0 = 80
[   62.541320] hda_codec: snd_hda_mixer_amp_switch_put
[   62.541325] hda_codec: hda_codec_amp_update
[   62.541329] hda_codec: hda_codec_amp_update
[   62.541379] hda_codec: snd_hda_codec_read verbs 00b 0 b00 2001 = 80
[   62.541420] hda_codec: snd_hda_codec_read verbs 00b 0 b00 1 = 80
[   62.541461] hda_codec: snd_hda_codec_read verbs 00b 0 b00 2002 = 80
[   62.541502] hda_codec: snd_hda_codec_read verbs 00b 0 b00 2 = 80
[   62.541544] hda_codec: snd_hda_codec_read verbs 00b 0 b00 2003 = 80
[   62.541585] hda_codec: snd_hda_codec_read verbs 00b 0 b00 3 = 80
[   62.541627] hda_codec: snd_hda_codec_read verbs 00b 0 b00 2004 = 80
[   62.541669] hda_codec: snd_hda_codec_read verbs 00b 0 b00 4 = 80
[   62.541732] hda_codec: snd_hda_codec_read verbs 018 0 f00 d = 270300
[   62.541774] hda_codec: snd_hda_mixer_amp_tlv
[   62.541787] hda_codec: snd_hda_mixer_amp_volume_put
[   62.541793] hda_codec: hda_codec_amp_update
[   62.541838] hda_codec: snd_hda_codec_read verbs 018 0 b00 2000 = 0
[   62.541843] hda_codec: hda_codec_amp_update
[   62.541897] hda_codec: snd_hda_codec_read verbs 018 0 b00 0 = 0
[   62.541947] hda_codec: snd_hda_mixer_amp_tlv
[   62.541960] hda_codec: snd_hda_mixer_amp_volume_put
[   62.541966] hda_codec: hda_codec_amp_update
[   62.542024] hda_codec: snd_hda_codec_read verbs 007 0 b00 2000 = 0
[   62.542030] hda_codec: hda_codec_amp_update
[   62.542088] hda_codec: snd_hda_codec_read verbs 007 0 b00 0 = 0
[   62.542111] hda_codec: snd_hda_mixer_amp_switch_put
[   62.542116] hda_codec: hda_codec_amp_update
[   62.542120] hda_codec: hda_codec_amp_update
[   62.542206] hda_codec: snd_hda_mixer_amp_volume_put
[   62.542212] hda_codec: hda_codec_amp_update
[   62.542216] hda_codec: put_vol_mute
[   62.542223] hda_codec: snd_hda_codec_write verbs 002 0 300 a039 = 0
[   62.542229] hda_codec: hda_codec_amp_update
[   62.542233] hda_codec: put_vol_mute
[   62.542240] hda_codec: snd_hda_codec_write verbs 002 0 300 9039 = 0
[   95.041936] hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x31
[   95.042520] hda_codec: snd_hda_codec_write verbs 002 0 706 50 = 0
[   95.047765] hda_codec: snd_hda_codec_write verbs 002 0 200 31 = 0
[   95.836276] hda_codec_cleanup_stream: NID=0x2
[   95.836309] hda_codec: snd_hda_codec_write verbs 002 0 706 0 = 0
[  117.228656] hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
[  117.228675] hda_codec: snd_hda_codec_write verbs 002 0 706 50 = 0
[  117.235714] hda_codec: snd_hda_codec_write verbs 002 0 200 4011 = 0
[  117.236027] hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
[  117.236065] hda_codec: snd_hda_codec_write verbs 002 0 706 50 = 0
[  117.246693] hda_codec: snd_hda_codec_write verbs 002 0 200 4011 = 0
[  117.271706] hda_codec_setup_stream: NID=0x7, stream=0x1, channel=0, format=0x4011
[  117.271729] hda_codec: snd_hda_codec_write verbs 007 0 706 10 = 0
[  117.279673] hda_codec: snd_hda_codec_write verbs 007 0 200 4011 = 0
[  117.279725] hda_codec_setup_stream: NID=0x7, stream=0x1, channel=0, format=0x4011
[  117.279735] hda_codec: snd_hda_codec_write verbs 007 0 706 10 = 0
[  117.287622] hda_codec: snd_hda_codec_write verbs 007 0 200 4011 = 0
[  118.349219] hda_codec_cleanup_stream: NID=0x7
[  118.349248] hda_codec: snd_hda_codec_write verbs 007 0 706 0 = 0
[  118.349315] hda_codec_cleanup_stream: NID=0x7
[  118.349330] hda_codec: snd_hda_codec_write verbs 007 0 706 0 = 0
[  118.352101] hda_codec_cleanup_stream: NID=0x2
[  118.352130] hda_codec: snd_hda_codec_write verbs 002 0 706 0 = 0
[  118.352200] hda_codec_cleanup_stream: NID=0x2
[  118.352217] hda_codec: snd_hda_codec_write verbs 002 0 706 0 = 0
[  118.491579] hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
[  118.491598] hda_codec: snd_hda_codec_write verbs 002 0 706 50 = 0
[  118.496677] hda_codec: snd_hda_codec_write verbs 002 0 200 4011 = 0
[  118.496745] hda_codec_setup_stream: NID=0x2, stream=0x5, channel=0, format=0x4011
[  118.496755] hda_codec: snd_hda_codec_write verbs 002 0 706 50 = 0
[  118.504693] hda_codec: snd_hda_codec_write verbs 002 0 200 4011 = 0
[  127.215768] hda_codec_cleanup_stream: NID=0x2
[  127.215799] hda_codec: snd_hda_codec_write verbs 002 0 706 0 = 0
[  127.215866] hda_codec_cleanup_stream: NID=0x2
[  127.215882] hda_codec: snd_hda_codec_write verbs 002 0 706 0 = 0

And what I initially used to get sound out from speaker:

AC VERB    DEC_PIN     OPERATION
-------    ---------   --------------------------------------------------------
# startup
#00170500 - 1         SET_POWER_STATE
#02050004 - 32         SET_COEF_INDEX
#02040849 - 32         SET_PROC_COEF
#02050004 - 32         SET_COEF_INDEX
#02040849 - 32         SET_PROC_COEF

00170500 02050004 02040849 02050004 02040849

# mute input amps
00737000 - 07(AMP_IN)  {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)}
00b37080 - 11(MIXER)   {0x0b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
00b37180 - 11(MIXER)   {0x0b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)},
00b37280 - 11(MIXER)   {0x0b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)},
00b37380 - 11(MIXER)   {0x0b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)},
00b37480 - 11(MIXER)   {0x0b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)},

00737000 00b37080 00b37180 00b37280 00b37380 00b37480

# setup output mixers 0x0c - 0x0e
0023b000 - 02(AMP_OUT) {0x02, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_ZERO},
0033b000 - 03(AMP_OUT) {0x03, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_ZERO},

0023b000 0033b000 

00c37000 - 12(MIXER)   {0x0c, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
00c37100 - 12(MIXER)   {0x0c, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)},
00d37000 - 13(MIXER)   {0x0d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
00d37100 - 13(MIXER)   {0x0d, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)},
00e37000 - 14(MIXER)   {0x0e, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
00e37100 - 14(MIXER)   {0x0e, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(1)},

00c37000 00c37100 00d37000 00d37100 00e37000 00e37100

01470740 - 20(PC_AOUT) {0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT},
015707c0 - 21(PC_AOUT) {0x15, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP},
01670740 - 22(PC_AOUT) {0x16, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT},
01870724 - 24(PC_AIN)  {0x18, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREF80},
01970724 - 25(PC_AOUT) {0x19, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREF80},
01a70720 - 26(PC_AIN)  {0x1a, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN},
01b70720 - 27(PC_AIN)  {0x1b, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN},

01470740 015707c0 01670740 01870724 01970724 01a70720 01b70720

0143b000 - 20(PC_AOUT) {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE},
0153b000 - 21(PC_AOUT) {0x15, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE},
0163b080 - 22(PC_AOUT) {0x16, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},
0183b080 - 24(PC_AIN)  {0x18, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},
0193b080 - 25(PC_AOUT) {0x19, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},
01a3b080 - 26(PC_AIN)  {0x1a, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},
01b3b080 - 27(PC_AIN)  {0x1b, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},

0143b000 0153b000 0163b080 0183b080 0193b080 01a3b080 01b3b080

01470100 - 20(PC_OUT)  {0x14, AC_VERB_SET_CONNECT_SEL, 0x00},
01570100 - 21(PC_OUT)  {0x15, AC_VERB_SET_CONNECT_SEL, 0x00},

01470100 01570100

        /* FIXME: use matrix-type input source selection */
        /* Mixer elements: 0x18, 19, 1a, 1b, 1d, 0b */
        /* Input mixer1: unmute Mic, F-Mic, Line, CD inputs */
02437000 - 36(MIXER)   {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
02437180 - 36(MIXER)   {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)},
02437280 - 36(MIXER)   {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)},
02437380 - 36(MIXER)   {0x24, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)},

02437000 02437180 02437280 02437380

01470c02 - 20(PC_OUT)  {0x14, AC_VERB_SET_EAPD_BTLENABLE, 2},
01570c02 - 21(PC_OUT)  {0x15, AC_VERB_SET_EAPD_BTLENABLE, 2},
01470c02 - 20(PC_OUT)  {0x14, AC_VERB_SET_EAPD_BTLENABLE, 2},
01570c02 - 21(PC_OUT)  {0x15, AC_VERB_SET_EAPD_BTLENABLE, 2},
01570884 - 21(PC_OUT)  {0x15, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | ALC880_HP_EVENT},

01470c02 01570c02 01470c02 01570c02 01570884

01470740 - 20(PC_OUT)  {0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT},
0143b000 - 20(PC_OUT)  {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE},
01470100 - 20(PC_OUT)  {0x14, AC_VERB_SET_CONNECT_SEL, 0x00},

01470740 0143b000 01470100

015707c0 - 21(PC_OUT)  {0x15, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP},
0153b000 - 21(PC_OUT)  {0x15, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE},
01570100 - 21(PC_OUT)  {0x15, AC_VERB_SET_CONNECT_SEL, 0x00},

015707c0 0153b000 01570100

01470740 - 20(PC_OUT)  {0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT},
0143b000 - 20(PC_OUT)  {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE},
01470100 - 20(PC_OUT)  {0x14, AC_VERB_SET_CONNECT_SEL, 0x00},

01470740 0143b000 01470100

01270720 - 18(PC_IN)   {0x12, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN},
01870724 - 24(PC_IN)   {0x18, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREF80},
0183b080 - 24(PC_IN)   {0x18, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
01470740 - 20(PC_AOUT) {0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT},

01270720 01870724 0183b080 01470740

01570101 - 21(PC_OUT)  {0x15, AC_VERB_SET_CONNECT_SEL, 0x01},
02370105 - 35(ASELECT) {0x23, AC_VERB_SET_CONNECT_SEL, 0x05},
0023b026 - 02(AMP_OUT) {0x02, AC_VERB_SET_AMP_GAIN_MUTE, 0xb026 },
00837019 - 08(AMP_IN)  {0x08, AC_VERB_SET_AMP_GAIN_MUTE, (0x7019 | (0x00 << 8))},
01270720 - 18(PC_IN)   {0x12, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN},
01870888 - 24(PC_IN)   {0x18, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | ALC880_MIC_EVENT},
01570884 - 21(PC_OUT)  {0x15, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | ALC880_HP_EVENT},

01570101 02370105 0023b026 00837019 01270720 01870888 01570884

I was trying to upload the files into the wiki but getting permission errors.
UPDATE: I have uploaded the kext into rapidshare: http://rapidshare.com/files/157602713/eee901kext4sound.zip.html
There are two AppleHDA.kext available in the zip file, AppleHDA269from268 was the original AppleHDA.kext from the 268 mod from Taruga's ALC268FIX Installer, and AppleHDA2691016 is a modified AppleHDA.kext uploaded by snickersmd on October 16. For the AppleHDA2691016 version, I had to add layout 12 into the Layouts in PostConstructionInitialization in the AppleHDAController.kext for the AppleAzalia.kext to work, but it kills the AppleHDA.kext (HDA generic codec driver does not load for some reason). Also, I have included a perl script to decipher the base64 encoded ConfigData… I don't really like to figure out all of those hex using Property List Editor… Use the following example to decode:

./decodeinfo.pl AppleHDA269from268/AppleHDA.kext/Contents/PlugIns/AppleHDAController.kext/Contents/Info.plist | less

Last edited on 1224995804|%e %b %Y, %H:%M %Z|agohover By hagglebeef + Show more

Re: AppleHDA.kext progress

elroy 1224992331|%e %b %Y, %H:%M %Z|agohover

Hey hagglebeef,

Awesome work dude. If you want to email me the files I'd be happy to host them on my site until someone with permissions can upload them here.

email me at elroy — the at symbol — elroyonline.net

Cheers

Re: AppleHDA.kext progress

Toonces 1224995847|%e %b %Y, %H:%M %Z|agohover

Excellent Hagglebeef! So basically, we are not setting enough of the config in the AppleHDA.kext we've been using. What about putting all of the setup in HDAEnabler? Have you tried that? HDAEnabler.kext is currently blank (or should be) but is capable of sending the setup verbs in it's info.plist.

Re: AppleHDA.kext progress

hagglebeef 1224996137|%e %b %Y, %H:%M %Z|agohover

I did try doing that with the new 10.5.5 kext, but that did not work. I have not try doing it with the older 268 converted version yet, plus I have not updated the path for it so not sure it would work off the bat. Worth a shot though.

Re: AppleHDA.kext progress

Toonces 1224996801|%e %b %Y, %H:%M %Z|agohover

If it doesn't work for AppleHDA, maybe it will work to setup for AppleAzalia? I just downloaded the files you uploaded and will start playing around with it as well. Thank You for the excellent info in your posts too!

Re: AppleHDA.kext progress

andif62 1225022081|%e %b %Y, %H:%M %Z|agohover

Did the install and de-install like others before:
remove AppleAzalia.kext -> reboot
install AppleHDA.kext from AppleHDA269from268 -> reboot
install AppleAzalia.kext again -> reboot
But no sound at all!
HD Audio Output is shown in Preferences
No input devices found

Re: AppleHDA.kext progress

hagglebeef 1225026535|%e %b %Y, %H:%M %Z|agohover

Andif62,

I use the AppleAzalia.kext package from the audio_kexts_eeepc.zip which automatically deletes the AppleHDA.kext when you install it. Hopefully that helps…

Re: AppleHDA.kext progress

Toonces 1225004338|%e %b %Y, %H:%M %Z|agohover

I can confirm that if you load the AppleHDA269from268 version provided by hagglebeef then delete it and install AppleAzaliaAudio.kext that sound does indeed work from the internal speakers on a 1000H. Doing the same with a similarly modded AppleHDA.kext from 10.5.5 (from Snickersmd) does not do the same thing. This is very promising as there is at least a way to get sound out of said previously silent speakers :D Great work Hagglebeef! I will upload dumps from Codeye's codec dump program and ioregistry explorer taken while sound is working in case it will help in comparing what could be different. If any of you need me to try or get any additional info while Azalia is loaded and working, please let me know. At least now we have some working stuff to compare to!

WooHoo! Progress…

Re: AppleHDA.kext progress

elroy 1225010933|%e %b %Y, %H:%M %Z|agohover

Same here. Following the instructions in hagglebeef's post I've been able to get the speakers working — kill them via reboot or sleep — and then get them working again.

If there is information that I can add to the pool, then please let me know (and let me know how to get said information).

Top work hagglebeef, and everyone else whose work has gotten us so far and so very close.

Re: AppleHDA.kext progress

hagglebeef 1225026364|%e %b %Y, %H:%M %Z|agohover

Toonces,

I was looking into why the mod AppleHDA from Snickersmd did not work for you and found that what I modify in the HDAEnabler could be the answer - let me know….

1:eee901kext4sound root# ./decodeinfo.pl /System/Library/Extensions/HDAEnabler.kext/Contents/Info.plist
<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>CFBundleDevelopmentRegion</key>
    <string>English</string>
    <key>CFBundleExecutable</key>
    <string>HDAEnabler</string>
    <key>CFBundleGetInfoString</key>
    <string>1.0.0d1, Copyright © 2008 by Kabyl</string>
    <key>CFBundleIdentifier</key>
    <string>com.kext.HDAEnabler</string>
    <key>CFBundleInfoDictionaryVersion</key>
    <string>6.0</string>
    <key>CFBundleName</key>
    <string>HDAEnabler</string>
    <key>CFBundlePackageType</key>
    <string>KEXT</string>
    <key>CFBundleSignature</key>
    <string>????</string>
    <key>CFBundleVersion</key>
    <string>1.0.0d1</string>
    <key>IOKitPersonalities</key>
    <dict>
        <key>HDAEnabler</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>com.kext.HDAEnabler</string>
            <key>HDAProperties</key>
            <dict>
                <key>PinConfigurations</key>
                <data>
<00170500 02050004 02050004 02040849>
                </data>
                <key>built-in</key>
                <data>
<00170500 02050004 02050004 02040849>
                </data>
                <key>layout-id</key>
                <data>
<0c000000>
                </data>
            </dict>
            <key>IOClass</key>
            <string>HDAEnabler</string>
            <key>IOPCIClassMatch</key>
            <string>0x04020000&amp;0xFFFE0000</string>
            <key>IOProviderClass</key>
            <string>IOPCIDevice</string>
        </dict>
    </dict>
    <key>OSBundleCompatibleVersion</key>
    <string>1.0.0d1</string>
    <key>OSBundleLibraries</key>
    <dict>
        <key>com.apple.iokit.IOPCIFamily</key>
        <string>1.0.0b1</string>
        <key>com.apple.kernel.iokit</key>
        <string>6.9.9</string>
    </dict>
    <key>OSBundleRequired</key>
    <string>Safe Boot</string>
</dict>
</plist>

The changes are in the PinConfigurations and built-in keys - I am not sure what built-in does, or if changing it helps, but that is what is currently in my HDAEnabler.

Last edited on 1225026741|%e %b %Y, %H:%M %Z|agohover By hagglebeef + Show more

Re: AppleHDA.kext progress

Toonces 1225134268|%e %b %Y, %H:%M %Z|agohover

hagglebeef, What I was thinking is putting the entire pin config string from the controller plist into HDAEnabler's PinConfigurations section. My HDAEnabler is actually empty for all those lines though I think LayoutID should have 12 dec. I don't know what the built-in key is used for but maybe someone who has communication with kabyl can ask about it.

From my understanding of HDAEnabler, since it runs prior to other audio kexts that it injects the appropriate config info that AppleHDA.kext is looking for. I would think that it might be possible to use HDAEnabler to inject what we need for AppleAzaliaAudio.kext as a start instead of loading the 269from268 AppleHDA.kext. That doesn't take care of sleep as far as I know but should take care of rebooting. The IOClassMatch may also need to be changed to the older style that AppleAzaliaAudio is expecting in order for a match to be made 0x27d88086 for the 1000H for example. (0x27defffff will also work for anything from what I recall)

Found an old guide for AppleAzaliaAudio.kext just as a reference: http://forum.insanelymac.com/index.php?showtopic=18642&st=0#

Re: AppleHDA.kext progress

snickersmd 1225143195|%e %b %Y, %H:%M %Z|agohover

Regarding the built-in line, I did look into that when I was researching HDA-enabler. Best source of information on this is on Netkas' forum; it is not specific to AppleHDA. It is a part of creating an EFI string, which has been successfully used to load audio completely with no driver hacking on fully compatible codecs.

I had considered the idea that we may ultimately need a hybrid hack that will consist of an EFI string being created by HDAEnabler together with the direct AppleHDA plist and binary hacking. The answers to properly loading the config are also probably staring us in the face in the form of EFI strings.

If anyone here has previous Hackintosh experience with EFI strings, I'd like to hear from them.

http://forum.netkas.org/index.php/topic,104.0.html, second post down has complete EFI string layout for audio that can be put into HDAenabler

Last edited on 1225150257|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

Toonces 1225164463|%e %b %Y, %H:%M %Z|agohover

I don't have a lot of time today but it's been exciting watching what has been going on. Basically, the EFI strings perform the same function as HDAEnabler. If you look at what is passed it is the same info along with the appropriate vendor strings that match it all up. If I get some time I will play with HDAEnabler and EFI Strings some more. Here is what goes in the audio EFI String for audio:

<key>PciRoot(0x1)/Pci(0x1b,0x0)</key>
   <dict>
      <key>PinConfigurations</key>
      <string></string>
      <key>built-in</key>
      <string>0x00</string>
      <key>layout-id</key>
      <string>0x0000000c</string>
      <key>revision-id</key>
      <string>0x00000001</string>
      <key>subsystem-id</key>
      <string>0x0000a002</string>
      <key>subsystem-vendor-id</key>
      <string>0x00001458</string>
      <key>vendor-id</key>
      <string>0x00008086</string>
   </dict>

Notice it's the same lines from HDAEnabler. I believe we need to add the complete config string as found in 269from268 and that should be enough to initialize AppleAzaliaAudio.kext on startup at the very least. maybe even when returning from sleep?? The key to AppleAzalia is just turning on the EAPD amp which is a new verb to any of these Apple kexts so it may or may not work simply because Apple didn't support it. One thing I don't agree on Snickers is that the AppleHDA is getting more generic. I look at the latest kexts vs something like AppleAzaliaAudio and if anything, they seem to be getting more specific. Apple Azalia pretty much tries to figure out what the pin configs are given nothing more than a codec match where the 10.5.5 kext has layouts and pathmaps that are specific to the chips apple uses. The latest one from the new macbook update gets even more complex since it adds support for the same codecs on a the new NVIDIA chipset. The only reason I could think of for Apple taking such a complicated route is to limit the number of working sound configs as they continue to release new hardware. They do appear however, to be sticking to the same realtek chips of the previous versions. Just attached to nforce chipset instead of ich. Anyways, I will continue to plug away at this as much as I can.

Re: AppleHDA.kext progress

snickersmd 1225171966|%e %b %Y, %H:%M %Z|agohover

Toonces,

Ah, semantics.

"Basically, the EFI strings perform the same function as HDAEnabler."

It's the other way around. EFI strings are the right way to do things, the way a true Mac passes hardware data to the OS, through an identifier in the firmware. HDAEnabler is a hack to create and load that string without EFI… and with the newer bootloaders that do EFI strings natively, it may or may not be necessary. This is an important distinction, because it helps us to understand what HDAEnabler was actually written to do, what it does for the configuration, and how we can use that to our ends. Because few of the ipis users are actually using EFI strings HDAEnabler is the definitive way to create them for us at this time, so we pattern our work in HDAEnabler after the work that has already been done with EFI strings for the EFI bootloader guys (among them, Kabyl is a prominent coder in their group).

"One thing I don't agree on Snickers is that the AppleHDA is getting more generic."

The fact that it's getting more complex doesn't mean they are specializing it. True specialization would mean that they would remove support for older chipsets or create separate legacy drivers for them. The way that Apple supports hardware means that each subsequent OS X release has to support all the hardware models that came before it. With each new hardware iteration, there are more chips to support. The driver is not getting exponentially bigger; they aren't bundling in separate code for each new codec chip. The fact that they have to support the new and the old together in one kext necessitates the use of a generic driver, so they have to go by UAA spec in order to maintain support. Recall that the bundled plugin kexts actually have names like PlatformDriver and GenericDriver, not RealtekDriver and Nforce driver. It just seems to get more complicated to us because things that work in older kexts like Azalia don't work anymore in newer kexts? That only means that they are changing the configuration specification to keep up with their updated driver code.

One of the major breakthroughs of the past week or so has less to do with the fact that we now have Azalia working and more to do with Linux-derived HDA codec troubleshooting courtesy of codeye and hagglebeef. Just because they don't seem to work as straightforwardly in the newer kexts doesn't mean Apple has shut us out. We just don't fully understand their plist configuration system, and the latest working hacks went around that completely.

Only reason I'm picking apart your statements (not trying to pick a fight ;)) is just to define a clear outline for the stages in the research we have yet to do. It was a great idea to start at the beginning with Azalia, as we should have known even way before hagglebeef produced his findings — because comatron already had his working, albeit just with headphones. As codeye suggested, there's an order that needs to be followed, and after getting stuff working on Azalia then we port over to HDA-older. And as soon as that is successful, we will probably have the insight to hack HDA-newer. Of course that planning doesn't make sense if we assume Apple is becoming less generic, so it is better to operate under the assumption that the driver is becoming universal.

Re: AppleHDA.kext progress

Toonces 1225176560|%e %b %Y, %H:%M %Z|agohover

Snickers,

I believe my statement is exactly true. Look at the data passed in each. What gives us the ability to abandon HDAEnabler is that the teams behind the EFI Emulators have given us a generic injector that happens to replace the specific ones. Whether it's the "right thing to do" or not is neither here nor there. Injection using EFI Strings just backs the injection process up a step in the boot process but they accomplish the same goal. In either case you still have to know the correct data to provide. and it does the same thing. There is no magic in either. They both do the same thing at different times in the boot process and both use the same data.

As far as getting more complex. What other reason would Apple have to take a driver that completely figures out and configures audio and add specific layouts and path maps? I know it's only a guess on my part but Apple's only interest is protecting their code from being easily executed on similar but non-Apple platforms. While I think it was pretty easy for me to load on my Dell 530 and didn't take much longer than doing a stock install (thanks to those that already did the legwork), it's not possible to just stick a retail disk in and go on a platform that is VERY close to one of their own. Apple uses EFI as an obscure copy protection. As it gets figured out and the emulation of their EFI implimentation gets better they have to discourage people in other ways. At least until (if) they ever decide to make OS X available to other platforms besides their own.

Now, as for major breakthroughs and such. I suggest you take a long look through this very thread and read it again. I know you are distracted by your medical board exams and I don't wish to add to the fire but every time you've picked apart my posts, it's been to shut down what I suggest we look at. You shut down comatron regarding Azalia. You shut me down when I suggested the answers we needed in order to figure out what is going on lies in the linux source. You shut me down when I suggested that the IOPCIClassMatch may be wrong. Now, here we are with sound out because someone took the time to look at why Azalia worked at least in part by comparing it to the linux source and the way the ALSA driver worked. Only now it's a breakthrough. I am all for a systematic approach but unless you know what the next steps are and are going to delineate what those steps are with your attention on what is going on, we have to try stuff out and see what happens then make decisions on what to try next. I have done a lot of playing around and have a very good idea of what should be in the layouts and pathmaps. The semi working 269from268 happens to have a non nested config and is very straight forward. It also happens to set the ALC269 chip up for a driver that is capable of using it (Azalia). So given that, why doesn't it work if it's got the correct config data? I have no idea and won't until I've tried every possible config option I can think of. The one difference I see when looking at Azalia vs. any of the AppleHDA.kext we have is that Mute works for Azalia. You can select it in Azalia and it's greyed out in all of the HDA configs. Why is that? What vital piece of setup are we missing? MuteGPIO? When I mess with that or even just send the verb to unmute an output, OS X immediately crashes. There's got to be something that the HDA drivers are doing differently. Some config that isn't right or something Apple has changed. Why else would everyone still be using AppleHDA from 10.5.0/10.5.1/10.5.2? We're not the only ones that can't get 10.5.5 sound working. I even tried it on my Dell which has a working 10.5.2 AppleHDA and 10.5.5's kext doesn't work with the same config data. And lastly, codeye was responding to my post where I suggested that we needed to look at the older AppleHDA versions. I really am not out for a fight but after being shut down at least 3 times for suggestions that have panned out when someone else just does them is getting a bit old. Your post makes it sound as if I am some lunatic just suggesting stuff out of the blue with no rhyme nor reason and I really don't feel that is the case. You're not the only busy person around here. In addition to a full time job as a Director of an IT department, I also run my own business and have 3 kids in school that all have after school activities 4 days out of the week. Yet I still manage to find time to test things and make quick decisions about what I am seeing. I may not be a programmer but I damn sure know how to troubleshoot problems. I've been doing it for a very long time.

Re: AppleHDA.kext progress

Diamondsw 1225177492|%e %b %Y, %H:%M %Z|agohover

As close as we are, let's all take a step back. I'm indebted to a lot of people here - snickersmd, toonces, codeye, and hagglebeef, especially - and I don't want to see any of you go the way Mr. X or Taruga disappeared.

Let's look at *all* options. We have a partially working driver now with Azalia. Might I suggest we learn all we can from getting it working 100%, then move to AppleHDA 10.5.2 with what we learn, and only then move on to AppleHDA 10.5.5? Or parallel development in multiple directions will work - sometimes discoveries on one project can have spillover to the other, as long as everyone keeps collaborating.

Take a break, keep it cool, and enjoy the sound pouring from our little Eee's. Again - thank you - ALL of you. :)

Re: AppleHDA.kext progress

snickersmd 1225178737|%e %b %Y, %H:%M %Z|agohover

Toonces,

Ouch. I wasn't trying to shut you down this time, and I certainly meant no disrespect. If ever I have countered you it is because I am thinking aloud with my own reasoning off the problem and as it so happens my reasoning is not always correct. But it is the thinking aloud and talking with you that helps me towards a better understanding of the problem and hopefully, my contribution to the solution. For me, arguing a point helps me think through a problem, but if you remember that each previous time I "shot" anyone down, I always added the caveat: keep trying it the way you see fit because if your method gets us there first, who cares what I think.

Secondly, I am no programmer. Your IT background is far more comprehensive than mine. What I bring to the table is years of experience with reverse engineering and disassembly, and it usually means I tend to do things a little backward. I never implied that you were more or less capable than I for anything here, so I really don't know where the "you're not the only busy person around here" rant is coming from.

All I have to say is I'm sorry if you took my argumentative nature as trying to bring you down. I will say it plainly that I have a great deal of respect for you and your work here on this forum. And yeah, I talk way more than I should and it shows in my typing style. At least twice on this thread I've said things that could probably have been said better. But I never, ever meant to say that your ideas were bad ones and then turn around and shower praise when someone else does them.

So, sorry. And I hope the next time you have a bright idea and I decide to counter it, just remember that I'm just thinking aloud and don't take it personally. I can pick out at least 3 posts (definitely more) where I have arrived at a conclusion based on hours of hacking only to realize how bad the idea was just as it was getting posted. Yet even with admin rights, I don't go around erasing stuff to avoid looking stupid. My point is that I admit that I'm not always right, but I still leave my thoughts in this forum as a sort of journal, so they can be revisited if it would help. It's my way of covering all the angles.

Ironic that I should take a few paragraphs to pollute the thread with drama after chasing away the "help me" posts into another thread in an attempt to streamline this thread. Sorry again for the extra garbage.

Friends?

Last edited on 1225178995|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

Toonces 1225210493|%e %b %Y, %H:%M %Z|agohover

Snickers,
I'll answer this and we can move on. The reason I took offense is not because of you thinking aloud or disagreeing or arguing with me. Those are all valid tools we have to use. My problem is that on more than one occasion now you end your post to me with a reminder to me that we have to be methodical and follow the proper path in order to figure this out. That says to me that either you do not believe I know what I am doing or that I am out in left field. It may or may not be what you meant but it is the way I took it.

That's all the further I'll comment on this in the thread. I have my 1000H at work with me today and plan on trying some work with EFI Strings as long as the battery holds out. Brightness control has to be next :)

Re: AppleHDA.kext progress

hagglebeef 1225216662|%e %b %Y, %H:%M %Z|agohover

Toonces,

Already have brightness control…. http://ipis-osx.wikidot.com/forum/t-91753/brightness-control

Re: AppleHDA.kext progress

Toonces 1225218696|%e %b %Y, %H:%M %Z|agohover

Thanks hagglebeef. I looked at that already but the AppleIntegratedFrameBuffer.kext I am using is different and doesn't have the same value at the stated location to edit.

Re: AppleHDA.kext progress

hagglebeef 1225224209|%e %b %Y, %H:%M %Z|agohover

Toonces,

I am using the latest OSX 10.5.5 kext for graphics which I modified to 27aeAppleIntelGMA950.kext and 27aeAppleIntelIntegratedFramebuffer.kext and put in the brightness control mod. Any particular reason you are using a different AppleIntelIntegratedFramebuffer.kext? Just curious.

UPDATE: I did not realize that the 10.5.5 patch was not put together here already. Had a version since september… Here you go… http://rapidshare.com/files/158469233/eee901and1000-10.5.5-GMA950-with-brightnesscontrol.zip Credit still goes to Codeye as I mention in this post… http://ipis-osx.wikidot.com/forum/t-91753/brightness-control

Last edited on 1225229177|%e %b %Y, %H:%M %Z|agohover By hagglebeef + Show more

Re: AppleHDA.kext progress

Toonces 1225250945|%e %b %Y, %H:%M %Z|agohover

Thanks again hagglebeef! I was using a supposed 10.5.5 kext and got sidetracked by ALC269 by the time I found out it was really an edit on the same old version that previous versions used. It worked so it wasn't a priority for me and now that you have given me the pre-modified one, it isn't a priority at all :)

Re: AppleHDA.kext progress

codeye 1225029277|%e %b %Y, %H:%M %Z|agohover

Guys,
Have azalia controlling the 269 codec at present - nice to hear something :-)
It behaves as expected on my machine sound goes off when EAPD is switched on/off NID 0x15
and muting the amps seems to work - no crashes. I noticed my "Node Dump" wasn't displaying
the correct amp-out info so I have fixed that and loaded yet another revision of codec_dump (0.3)
and verb command plus (0.2) - I think they should be accurate now (sorry!). Time to see what happens to
the settings on sleep and see if they can be restarted without re-install.

Re: AppleHDA.kext progress

hagglebeef 1225031113|%e %b %Y, %H:%M %Z|agohover

Codeye,

Did not see that you already introduced another version of the codec dump, ignore my previous post with the results from the codec_dump 0.2

Re: AppleHDA.kext progress

codeye 1225031621|%e %b %Y, %H:%M %Z|agohover

hagglebeef,
sorry screwed up the previous version. Looks like you can turn sound back on by reenabling the EAPD on NID 0x14 - verb command 0x01470c02 after sleep - no reboot required!

Re: AppleHDA.kext progress

hagglebeef 1225032336|%e %b %Y, %H:%M %Z|agohover

Codeye,

Good to hear that you are getting better results than I was able to. I was trying to pursue the AppleHDA kext method because that will have the power controls lacking in the Azalia kext, but looks like the path setting could be overwriting the preset verbs. I was trying to get it working with the PostConstructionInitialization setting, but that just made AppleHDA not load. I also notice that there is a PreservePinConfigurations boolean setting in the AppleHDAController kext. Not sure what it does, but could help us to get the AppleHDA kext working.

Re: AppleHDA.kext progress

codeye 1225032486|%e %b %Y, %H:%M %Z|agohover

Just to let you know sending the same verb to the codec on reboot also works. No need to remove/reinstall kexts.
This makes sense and gives me a bit more confidence in sorting out the appleHDA.kext

Re: AppleHDA.kext progress

codeye 1225032856|%e %b %Y, %H:%M %Z|agohover

Sorry hagglebeef,
I didn't see your post. It sounds like you are definitely onto something with the way the alc268 loads up and works, I haven't had the chance to examine it closely but it may well provide the key to cracking this - keep up the good work!

Re: AppleHDA.kext progress

akrylic 1225059457|%e %b %Y, %H:%M %Z|agohover

It's work with my lenovo s10!! thank yu haglebeef :)

Re: AppleHDA.kext progress

takabusu 1225083445|%e %b %Y, %H:%M %Z|agohover

I don't know how can I make the sound work…
Need help! Thanks alot

Re: AppleHDA.kext progress

takabusu 1225089151|%e %b %Y, %H:%M %Z|agohover

now it works great thx
sorry i didn read carefully….

Thanks again

Re: AppleHDA.kext progress

Diamondsw 1225086474|%e %b %Y, %H:%M %Z|agohover

Now you did it - you made the masses think it's done. :-)

Re: AppleHDA.kext progress

snickersmd 1225098109|%e %b %Y, %H:%M %Z|agohover

Hey everyone,

Sorry for my absence, but as I have alluded to before, review for medical boards restrict me from hacking as much as I'd like.

All the evidence is showing us that it has always been a question of correct plist manipulation (with the correct codec settings). Not only am I happy that we are nearing the end of the road (although I am aware that there is still a bit more poking around before we get everything working.), but we have collectively offered a truly comprehensive guide into AppleHDA hacking that just didn't exist before. It's not only the ipis users, and all other ALC269 users among our netbook brethren, but our work, combined with the MadTux guides and codeye's tools have brought new light and understanding to AppleHDA so that Taruga can vacation for however long he wants without leaving unsupported codecs in the dark. Again, a big thanks to the whole community.

At any rate, I am glad to see the progress that has been made in the short time that I have been gone. Congratulations to all participants. My only question is this:

Hagglebeef, why didn't you show up weeks before, to save me, codeye, and Toonces all the grief? ;D

Re: AppleHDA.kext progress

codeye 1225102738|%e %b %Y, %H:%M %Z|agohover

Snickers,
Good to see you back! Hagglebeef is definitely on the money with his approach - I can confirm from a quick check by sending 0x02050004 in controller.plist that this changes the setting in the codec on viewing it from verb_command_plus0.2 after reboot. I think we can use the appleHDA.kext from ALC268 and modify the AppleHDAPLatform with your setup and plug in the appropriate list of verbs from Hagglebeef (or from alsa's patch-realtek.c) and interesting things should happen. My feeling is we avoid 10.5.5 kext at present and use 10.5.2. Does anyone have any other thoughts on this one way or the other?

Re: AppleHDA.kext progress

snickersmd 1225104221|%e %b %Y, %H:%M %Z|agohover

My thoughts on what kext to use:

The changes that we have observed from version to version are evidence that Apple is tweaking their driver to be as universal as the Microsoft UAA Class Driver: I think it's inevitable as they build more and more Intel-based units each with a potentially different codec chip. So it's important that we keep testing our progress on 10.5.5.

However, I agree that we should concentrate on the kext which is showing us the most love ;) Get one working, then find out what has changed from the older kext to the newer versions to keep up with Apple. There's no sense in trying to adapt 10.5.5 before we even fully understand how the codec should work with earlier kexts. I think all energy should focus on getting these latest developments to be usable with a minimal of hassle, then adapt the changes upstream. The 10.5.5 kext isn't going anywhere, our previous work has been recorded here, so we can always pick 10.5.5 back where we left off once we get sound up and running with any other older kext such as 10.5.2.

We can also continue developing it in parallel, so long as the priority remains clear: we get sound working first no matter what — gotta crawl before we can walk ;)

Now a little OT: What do you think happened to the venerable Mr. X?
A: Probably threw his EeePC out the window after he played with AppleHDA.kext. :D

Re: AppleHDA.kext progress

Rodime 1225110556|%e %b %Y, %H:%M %Z|agohover

wonderful work. I'm looking forward to giving this a shot on my latest new toy…

Re: AppleHDA.kext progress

hagglebeef 1225112484|%e %b %Y, %H:%M %Z|agohover

Codeye and Snickers,

I agree we should look at the 268 mod AppleHDA.kext for now. I have been trying to get mod AppleHDA 10.5.5 to work with the 269 preset verbs, but having no luck. I was doing on 10.5.5 because everyone seems to be going in that direction. May be time to learn to crawl before we walk as Snickers says.

Re: AppleHDA.kext progress

MacLovin 1225112491|%e %b %Y, %H:%M %Z|agohover

Codeye

Did u say that you modified hagglebeefs kext to make it work upon sleep and reboot? If so, can you upload it and provide a brief installation guide! That would be very helpful! Thanks!

Re: AppleHDA.kext progress

hagglebeef 1225113225|%e %b %Y, %H:%M %Z|agohover

Codeye,

Finally rebooted my eee 901 (hard to do when you finally have sound :)) and tested your latest verb_command_plus0.2 app - works like a champ! No need to do that those re-installs finally. Great work. Now just have to get off my butt and start looking at that modified AppleHDA269from268 again.

Wiki Membership for File Upload Permissions

snickersmd 1225117102|%e %b %Y, %H:%M %Z|agohover

Toonces, strongesthylian, hagglebeef, and anyone else interested:

I would like to extend membership to you in order to better facilitate our work on AppleHDA as well as other parts of OS X on the ipis. However, it seems that the invites have never been received (in the case of Toonces and strongesthylian). Wikidot seems to have its quirks. Let's try something else — instead of me sending the invites, use the "join" link in the top bar to request membership, and see if I get a prompt to approve it.

Membership should give you wiki editing and upload rights.

Hope this fixes the problem.

Re: Wiki Membership for File Upload Permissions

hagglebeef 1225130739|%e %b %Y, %H:%M %Z|agohover

Snickers,

Thanks for trying to extend the membership to me, but still cannot join after using the "join" link. Get the following…

You can not apply.
It seems you have already applied for membership.

Let me know what to try next.

Re: Wiki Membership for File Upload Permissions

Toonces 1225133273|%e %b %Y, %H:%M %Z|agohover

Snickers, I also get the same error that hagglebeef posted above. I sent a join request over the weekend.

Re: Wiki Membership for File Upload Permissions

snickersmd 1225142120|%e %b %Y, %H:%M %Z|agohover

Stupid wikidot, stupid me.

I thought I would get system notifications anytime someone applied for membership. Guess not. Lo and behold the admin applications page where there were a crapload of unanswered applications.

You should all be members now, although some applicants, I don't know if they're really intending to help the wiki. Not declining them right away but I'm not inclined to accept either.

Anyhoo… welcome.

Re: AppleHDA.kext progress

QuinnStorm 1225128647|%e %b %Y, %H:%M %Z|agohover

Could someone please gather and post what's necessary to get azalia working?

I'm trying to follow this but its a little incoherent.

I know its not a real solution, but I'd like to try it.

Also, I know the verb needs sent on reboot/sleep — does it survive power-off or does it require the reinstall on power-off?

Re: AppleHDA.kext progress

snickersmd 1225142747|%e %b %Y, %H:%M %Z|agohover

Hi (Not just to QuinnStorm but to everyone asking for a guide)

I think that's a great idea, but this is a development thread. Why not start a new topic in the forum and collate the data yourself (or with a group of people), for the community? The development thread is huge and perhaps it would be more streamlined if we could separate the actual raw testing data and discussions from the help requests from starting newbies and potential testers alike.

I hope I'm not coming off as condescending, because I truly support this community. Everyone here is on borrowed time. It's great when a dev can sit and prep a guide, but this thread is evidence enough how much time goes into actually testing this. If you write a guide and publish it in a separate thread, we will be happy to edit it, make corrections and additions as necessary, etc. I know the reason you asked for a guide is because the thread is hard to follow in the first place; but at the least, read the posts and put together a draft of how you understand the process and the whole community will help flesh it out together.

Last edited on 1225143487|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

codeye 1225156310|%e %b %Y, %H:%M %Z|agohover

elroy has started a thread to explain how to get azalia working, can all posts relevant to that topic please be posted over there - thanks!

Re: AppleHDA.kext progress

codeye 1225196101|%e %b %Y, %H:%M %Z|agohover

I know I'm meant to stay on topic but see over on the azalia thread for headphones working as well!
I think i'm getting the hang of this ;-)

Last edited on 1225196251|%e %b %Y, %H:%M %Z|agohover By codeye + Show more

Re: AppleHDA.kext progress

hagglebeef 1225204052|%e %b %Y, %H:%M %Z|agohover

I have been modifying the 269from268 kext and have stripped it down to just the internal speakers, still no sound. When I dump the codec it looks almost identical to the one from the Azalia kext that works, which makes me think that there is some filtering going on in the AppleHDA generic codec driver. Below is a comparison between the codec dumps of the two drivers. The one on the right is a working Azalia and the one on the left is a non-functioning HDA with widgets for the intspeakers but not much else. Anyone have any suggestion on what to do next? Getting a bit frustrated here…

root# diff -by AppleAza.txt AppleHda.txt
Vendor Id: 0x10ec0269                                             Vendor Id: 0x10ec0269
Revision Id: 0x00100004                                           Revision Id: 0x00100004
Node 0x2 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out          Node 0x2 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out 
Amp-Out caps:  ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0       Amp-Out caps:  ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals:  [0x40 0x3f]                                      | Amp-Out vals:  [0x3f 0x3f]
Converter: stream=1, channel=0                                    Converter: stream=1, channel=0
Node 0x3 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out          Node 0x3 [Audio Output] wcaps 0x0000001d: Stereo Amp-Out 
Amp-Out caps:  ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0       Amp-Out caps:  ofs=0x3f, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals:  [0x00 0x00]                                        Amp-Out vals:  [0x00 0x00]
Converter: stream=0, channel=0                                    Converter: stream=0, channel=0
Node 0x4 [Vendor Defined Widget] wcaps 0x00f00000: Mono           Node 0x4 [Vendor Defined Widget] wcaps 0x00f00000: Mono 
Node 0x5 [Vendor Defined Widget] wcaps 0x00f00000: Mono           Node 0x5 [Vendor Defined Widget] wcaps 0x00f00000: Mono 
Node 0x6 [Audio Output] wcaps 0x00000211: Stereo Digital          Node 0x6 [Audio Output] wcaps 0x00000211: Stereo Digital 
Converter: stream=0, channel=0                                    Converter: stream=0, channel=0
Node 0x7 [Audio Input] wcaps 0x0010011b: Stereo Amp-In            Node 0x7 [Audio Input] wcaps 0x0010011b: Stereo Amp-In 
Amp-In caps:  ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1        Amp-In caps:  ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1
Amp-In vals:  [0x80 0x80]                                       | Amp-In vals:  [0x00 0x00] 
Converter: stream=0, channel=0                                    Converter: stream=0, channel=0
Connection: 1                                                     Connection: 1
Node 0x8 [Audio Input] wcaps 0x0010011b: Stereo Amp-In            Node 0x8 [Audio Input] wcaps 0x0010011b: Stereo Amp-In 
Amp-In caps:  ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1        Amp-In caps:  ofs=0x11, nsteps=0x2e, stepsize=0x03, mute=1
Amp-In vals:  [0x80 0x80]                                         Amp-In vals:  [0x80 0x80] 
Converter: stream=0, channel=0                                    Converter: stream=0, channel=0
Connection: 1                                                     Connection: 1
Node 0x9 [Vendor Defined Widget] wcaps 0x00f00000: Mono           Node 0x9 [Vendor Defined Widget] wcaps 0x00f00000: Mono 
Connection: 1                                                     Connection: 1
Node 0xA [Vendor Defined Widget] wcaps 0x00f00000: Mono           Node 0xA [Vendor Defined Widget] wcaps 0x00f00000: Mono 
Connection: 1                                                     Connection: 1
Node 0xB [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In            Node 0xB [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In 
Amp-In caps:  ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1        Amp-In caps:  ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]     Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
Connection: 5                                                     Connection: 5
Node 0xC [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In            Node 0xC [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In 
Amp-In caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1        Amp-In caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals:  [0x00 0x00] [0x80 0x80]                           | Amp-In vals:  [0x00 0x00] [0x00 0x00] 
Connection: 2                                                     Connection: 2
Node 0xD [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In            Node 0xD [Audio Mixer] wcaps 0x0020010b: Stereo Amp-In 
Amp-In caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1        Amp-In caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals:  [0x00 0x00] [0x00 0x00]                             Amp-In vals:  [0x00 0x00] [0x00 0x00] 
Connection: 2                                                     Connection: 2
Node 0xE [Audio Mixer] wcaps 0x0020010a: Mono Amp-In              Node 0xE [Audio Mixer] wcaps 0x0020010a: Mono Amp-In 
Amp-In caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1        Amp-In caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals:  [0x00 0x00] [0x00 0x00]                             Amp-In vals:  [0x00 0x00] [0x00 0x00] 
Connection: 2                                                     Connection: 2
Node 0xF [Vendor Defined Widget] wcaps 0x00f00000: Mono           Node 0xF [Vendor Defined Widget] wcaps 0x00f00000: Mono 
Connection: 2                                                     Connection: 2
Node 0x10 [Audio Output] wcaps 0x00000211: Stereo Digital         Node 0x10 [Audio Output] wcaps 0x00000211: Stereo Digital 
Converter: stream=0, channel=0                                    Converter: stream=0, channel=0
Connection: 2                                                     Connection: 2
Node 0x11 [Pin Complex] wcaps 0x00400380: Mono Digital            Node 0x11 [Pin Complex] wcaps 0x00400380: Mono Digital 
Pincap 0x00000014: OUT Detect                                     Pincap 0x00000014: OUT Detect 
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear                 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear 
Conn = 1/8 , Colour = Black                                       Conn = 1/8 , Colour = Black 
DefAssociation = 0xF, Sequence = 0x0                              DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE                                                Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ                                      Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0                                     Unsolicited: tag=0, enabled=0
Connection: 2                                                     Connection: 2
Node 0x12 [Pin Complex] wcaps 0x00400001: Stereo                  Node 0x12 [Pin Complex] wcaps 0x00400001: Stereo 
Pincap 0x00000020: IN                                             Pincap 0x00000020: IN 
Pin Default 0x99a30920: [Fixed] Mic In at Int ATAPI               Pin Default 0x99a30920: [Fixed] Mic In at Int ATAPI
Conn = ATAPI , Colour = Unknown                                   Conn = ATAPI , Colour = Unknown 
DefAssociation = 0x2, Sequence = 0x0                              DefAssociation = 0x2, Sequence = 0x0
Misc = NO_PRESENCE                                                Misc = NO_PRESENCE
Pin-ctls: 0x20: IN VREF_HIZ                                       Pin-ctls: 0x20: IN VREF_HIZ
Connection: 2                                                     Connection: 2
Node 0x13 [Vendor Defined Widget] wcaps 0x00f00000: Mono          Node 0x13 [Vendor Defined Widget] wcaps 0x00f00000: Mono 
Connection: 2                                                     Connection: 2
Node 0x14 [Pin Complex] wcaps 0x0040010d: Stereo Amp-Out          Node 0x14 [Pin Complex] wcaps 0x0040010d: Stereo Amp-Out 
Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1       Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals:  [0x00 0x00]                                        Amp-Out vals:  [0x00 0x00]
Pincap 0x00010050: OUT EAPD Balanced                              Pincap 0x00010050: OUT EAPD Balanced 
EAPD 0x2:EAPD                                                     EAPD 0x2:EAPD
Pin Default 0x99130110: [Fixed] Speaker at Int ATAPI              Pin Default 0x99130110: [Fixed] Speaker at Int ATAPI
Conn = ATAPI , Colour = Unknown                                   Conn = ATAPI , Colour = Unknown 
DefAssociation = 0x1, Sequence = 0x0                              DefAssociation = 0x1, Sequence = 0x0
Misc = NO_PRESENCE                                                Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ                                      Pin-ctls: 0x40: OUT VREF_HIZ
Connection: 2                                                     Connection: 2
Node 0x15 [Pin Complex] wcaps 0x0040018d: Stereo Amp-Out          Node 0x15 [Pin Complex] wcaps 0x0040018d: Stereo Amp-Out 
Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1       Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals:  [0x00 0x00]                                        Amp-Out vals:  [0x00 0x00]
Pincap 0x0001001c: OUT HP EAPD Detect                             Pincap 0x0001001c: OUT HP EAPD Detect 
EAPD 0x2:EAPD                                                     EAPD 0x2:EAPD
Pin Default 0x0121401f: [Jack] HP Out at Ext Rear                 Pin Default 0x0121401f: [Jack] HP Out at Ext Rear 
Conn = 1/8 , Colour = Green                                       Conn = 1/8 , Colour = Green 
DefAssociation = 0x1, Sequence = 0xF                              DefAssociation = 0x1, Sequence = 0xF
Pin-ctls: 0xc0: OUT HP VREF_HIZ                                   Pin-ctls: 0xc0: OUT HP VREF_HIZ
Unsolicited: tag=4, enabled=1                                   | Unsolicited: tag=3, enabled=1
Connection: 2                                                     Connection: 2
Node 0x16 [Pin Complex] wcaps 0x0040010c: Mono Amp-Out            Node 0x16 [Pin Complex] wcaps 0x0040010c: Mono Amp-Out 
Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1       Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals:  [0x80 0x80]                                        Amp-Out vals:  [0x80 0x80]
Pincap 0x00000010: OUT                                            Pincap 0x00000010: OUT 
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear                 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear 
Conn = 1/8 , Colour = Black                                       Conn = 1/8 , Colour = Black 
DefAssociation = 0xF, Sequence = 0x0                              DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE                                                Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ                                      Pin-ctls: 0x40: OUT VREF_HIZ
Connection: 2                                                     Connection: 2
Node 0x17 [Vendor Defined Widget] wcaps 0x00f00000: Mono          Node 0x17 [Vendor Defined Widget] wcaps 0x00f00000: Mono 
Connection: 2                                                     Connection: 2
Node 0x18 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-O     Node 0x18 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-O
Amp-In caps:  ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0        Amp-In caps:  ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals:  [0x03 0x03] [0x00 0x00]                             Amp-In vals:  [0x03 0x03] [0x00 0x00] 
Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1       Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals:  [0x00 0x00]                                      | Amp-Out vals:  [0x80 0x80]
Pincap 0x00003734: IN OUT Detect                                  Pincap 0x00003734: IN OUT Detect 
Pin Default 0x01a19830: [Jack] Mic In at Ext Rear                 Pin Default 0x01a19830: [Jack] Mic In at Ext Rear 
Conn = 1/8 , Colour = Pink                                        Conn = 1/8 , Colour = Pink 
DefAssociation = 0x3, Sequence = 0x0                              DefAssociation = 0x3, Sequence = 0x0
Pin-ctls: 0x24: IN VREF_80                                        Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=0, enabled=0                                     Unsolicited: tag=0, enabled=0
Connection: 2                                                     Connection: 2
Node 0x19 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-O     Node 0x19 [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-O
Amp-In caps:  ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0        Amp-In caps:  ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals:  [0x00 0x00] [0x00 0x00]                             Amp-In vals:  [0x00 0x00] [0x00 0x00] 
Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1       Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals:  [0x80 0x80]                                        Amp-Out vals:  [0x80 0x80]
Pincap 0x00003734: IN OUT Detect                                  Pincap 0x00003734: IN OUT Detect 
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear                 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear 
Conn = 1/8 , Colour = Black                                       Conn = 1/8 , Colour = Black 
DefAssociation = 0xF, Sequence = 0x0                              DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE                                                Misc = NO_PRESENCE
Pin-ctls: 0x44: OUT VREF_80                                       Pin-ctls: 0x44: OUT VREF_80
Unsolicited: tag=0, enabled=0                                     Unsolicited: tag=0, enabled=0
Connection: 2                                                     Connection: 2
Node 0x1A [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-O     Node 0x1A [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-O
Amp-In caps:  ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0        Amp-In caps:  ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals:  [0x00 0x00] [0x00 0x00]                             Amp-In vals:  [0x00 0x00] [0x00 0x00] 
Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1       Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals:  [0x80 0x80]                                        Amp-Out vals:  [0x80 0x80]
Pincap 0x0000373c: IN OUT HP Detect                               Pincap 0x0000373c: IN OUT HP Detect 
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear                 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear 
Conn = 1/8 , Colour = Black                                       Conn = 1/8 , Colour = Black 
DefAssociation = 0xF, Sequence = 0x0                              DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE                                                Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ                                      Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0                                     Unsolicited: tag=0, enabled=0
Connection: 2                                                     Connection: 2
Node 0x1B [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-O     Node 0x1B [Pin Complex] wcaps 0x0040018f: Stereo Amp-In Amp-O
Amp-In caps:  ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0        Amp-In caps:  ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals:  [0x00 0x00] [0x00 0x00]                             Amp-In vals:  [0x00 0x00] [0x00 0x00] 
Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1       Amp-Out caps:  ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals:  [0x80 0x80]                                        Amp-Out vals:  [0x80 0x80]
Pincap 0x00003734: IN OUT Detect                                  Pincap 0x00003734: IN OUT Detect 
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear                 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear 
Conn = 1/8 , Colour = Black                                       Conn = 1/8 , Colour = Black 
DefAssociation = 0xF, Sequence = 0x0                              DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE                                                Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ                                      Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0                                     Unsolicited: tag=0, enabled=0
Connection: 2                                                     Connection: 2
Node 0x1C [Vendor Defined Widget] wcaps 0x00f00000: Mono          Node 0x1C [Vendor Defined Widget] wcaps 0x00f00000: Mono 
Connection: 2                                                     Connection: 2
Node 0x1D [Pin Complex] wcaps 0x00400000: Mono                    Node 0x1D [Pin Complex] wcaps 0x00400000: Mono 
Pincap 0x00000020: IN                                             Pincap 0x00000020: IN 
Pin Default 0x4005822d: [N/A] Line Out at Ext N/A                 Pin Default 0x4005822d: [N/A] Line Out at Ext N/A 
Conn = Optical , Colour = Purple                                  Conn = Optical , Colour = Purple 
DefAssociation = 0x2, Sequence = 0xD                              DefAssociation = 0x2, Sequence = 0xD
Pin-ctls: 0x00: VREF_HIZ                                          Pin-ctls: 0x00: VREF_HIZ
Connection: 2                                                     Connection: 2
Node 0x1E [Pin Complex] wcaps 0x00400380: Mono Digital            Node 0x1E [Pin Complex] wcaps 0x00400380: Mono Digital 
Pincap 0x00000014: OUT Detect                                     Pincap 0x00000014: OUT Detect 
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear                 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear 
Conn = 1/8 , Colour = Black                                       Conn = 1/8 , Colour = Black 
DefAssociation = 0xF, Sequence = 0x0                              DefAssociation = 0xF, Sequence = 0x0
Misc = NO_PRESENCE                                                Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT VREF_HIZ                                      Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=0, enabled=0                                     Unsolicited: tag=0, enabled=0
Connection: 2                                                     Connection: 2
Node 0x1F [Vendor Defined Widget] wcaps 0x00f00000: Mono          Node 0x1F [Vendor Defined Widget] wcaps 0x00f00000: Mono 
Connection: 2                                                     Connection: 2
Node 0x20 [Vendor Defined Widget] wcaps 0x00f00040: Mono          Node 0x20 [Vendor Defined Widget] wcaps 0x00f00040: Mono 
Connection: 2                                                     Connection: 2
Node 0x21 [Vendor Defined Widget] wcaps 0x00f00000: Mono          Node 0x21 [Vendor Defined Widget] wcaps 0x00f00000: Mono 
Connection: 2                                                     Connection: 2
Node 0x22 [Vendor Defined Widget] wcaps 0x00f00000: Mono          Node 0x22 [Vendor Defined Widget] wcaps 0x00f00000: Mono 
Connection: 2                                                     Connection: 2
Node 0x23 [Audio Selector] wcaps 0x00300101: Stereo               Node 0x23 [Audio Selector] wcaps 0x00300101: Stereo 
Connection: 2                                                     Connection: 2

Re: AppleHDA.kext progress

Toonces 1225211013|%e %b %Y, %H:%M %Z|agohover

hagglebeef, what do you have in your pinconfigs and post initialization? I was just looking at that (again) and am wondering why the original AppleHDA.kext has multiple entries for the same codecid. If you grab an unmodified AppleHDA.kext and take a look. There are 4 entries for the ALC885 codecid. the second one has PreservePinconfigs with a checked box and just 2 pinconfig entries. Could these additional layouts be what is referenced in post initialization? It may not make a difference if they're not there with earlier chips but we have that damn amp to turn on at the very least.

Re: AppleHDA.kext progress

hagglebeef 1225216884|%e %b %Y, %H:%M %Z|agohover

Toonces,

I may take a look at that when my brain is less fried…

Re: AppleHDA.kext progress

codeye 1225237415|%e %b %Y, %H:%M %Z|agohover

Toonces,
I think the reason for multiple entries is similar to alsa, most of the codec behaves the correct way but some extra tweaking is needed depending on which model 885 is in the apple (eg macpro vs macbook).

hagglebeef,
If you want to try something perhaps looking at the debug code that the aspire spits out with your modified alsa driver and compare that to the codec verbs that alc268fix uses to set the aspires sound up under "os x". Does sound work on your aspire under "os x"?

I was thrown off the scent much earlier over at Tarugas website when someone lamented how different the ALC268 and ALC269 were - I'm hoping its their similarities that sort this out for us.

Just a bit of a rant but it really is annoying that Taruga (or someone with a similarly degree of understanding of the realtek codec) was aware that injecting a sequence of verbs was important with the newer codecs, was able to do this successfully, but didn't want to document his finding for some reason - it really has slowed us down a heap!

Re: AppleHDA.kext progress

Toonces 1225260060|%e %b %Y, %H:%M %Z|agohover

Hi Codeye, I looked over an unmodified AppleHDA.kext from the 2.1 macbook update and was just looking at the Controller Info.plist. I am sure you're right about the use. The other thing I kept going back to is the PostConstructionInitialization. In that there is a list of 4 layoutid's that correspond to layouts inside the controller.kext. They don't reference layouts in the Platform Info.plist. of that list of 21 layouts are 4 that are referenced by the ALC885 codecid. The interesting ones are the first layout (layoutid 0) which appears to set the controller up with a complete list of pinconfigs (though it doesn't include the entire chip, just the active nodes & no other initialization verbs) and the 3rd one (layoutid 36) which contains a just 2 verbs to initialize the mic & line in. The interesting thing is it also contains PreservePinConfigs whith a checked box. layoutid 36 is called by PostConstructionInitialization. In looking at the 10.5.5 AppleHDA.kext that snickers last uploaded on the 16th, item 3 is also called LayoutID 12 but with the original codecid. I think that may have been changed but the codecid wasn't. I also wonder with multiple layoutid 12's if that may be causing an issue even though they have different codecids.

Anyways, the reason for bringing all this up is just that I think we might just not have the right data in the right item numbers for correct configuration of the codec. I am thinking that the intial layoutid 12 that we use there should have the entire initialization as found in the 269from268 codec and then the specific verbs for turning on EAPD and setting the appropriate mute verbs should be in item 3 and called by PostConstructionInitialization. I don't know if it will give us sound or not but just makes more sense with how it looks like those other layouts are used.

I know the mic widget under PostConstructionInitialization is wrong as well but until sound out can work it's just an observation and not something that I will probably correct in trying to get a squeek out of AppleHDA.kext.

Re: AppleHDA.kext progress

snickersmd 1225261047|%e %b %Y, %H:%M %Z|agohover

I was playing with PostConstructionInitialiazation (PCI) last night as well, as I had the same idea about the setting. It would appear it is used to send extra verbs to nodes after the driver has initialized.

However, when I tried plugging in the verbs that we are using on Azalia and directed it towards the right node, I got some errors about lacking MicAttributes. So unfortunately, I have reason to believe that the PCI doesn't do what we would have hoped. I'm willing to bet it's a hard coded routine in the driver written specifically to address verb needs on Realtek microphone nodes.

I am still, however, only playing with 10.5.5 kexts. There is a possibility this could be different in the latest MacBook update kexts.

Odd too, Toonces, I thought the same thing with that Mic Widget. There is no Node 39 in any layout I've seen. Perhaps it is a virtual node?

Another thing I tried was to look at this layout 0 and multiple layout per codec scenarios. I surmised that Layout 0 is the default raw config, and modifications are made by calling the other DefaultConfig sets that in turn refer to different layouts with different characteristics. So I put the whole default raw config in and named it Layout 0, and then I took our new found verbs, set that up to point to Layout 12, then rebooted. No dice. Worse, absolutely no config was present in IO Registry.

My assumption with that is that since we are hacking detection with HDAEnabler, the Layout ID is always hardcoded to 12. So in the case of a codec that needs to jump around, we would never be able to do it so long as HDAEnabler forces Layout 12. Unfortunately, we have no source code to HDAEnabler, and I don't know if Kabyl would like to come over and make HDAEnabler do more than it does just for us, would he? If it is even an issue at all, that is. All the more reason for us to have an injecting kext of our own specifically designed to do dynamic audio layout changes.

coders… <sigh>

Last edited on 1225262191|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

Toonces 1225267461|%e %b %Y, %H:%M %Z|agohover

Funny, I was just going through a similar process and actually decided set the mic attributes though I haven't tried the new kext out yet since I am not done modifying it. From what I can tell, the node should be changed from 39 to 18 (0x12) and the pinconfig to 2577598752 (decimalized default pinconfig for node 0x12 from linux dump).

One odd thing I noticed as I am going through ever node in the unhacked 2.1 update kext. There's absolutely no layouts or pathmaps for the ALC262 codec. That seems really strange to me since the codec is in the driver. The rest of the codecs and even the new ALC885 on nforce is all there (along with something new called a mikey driver) but nothing for the ALC262. Soooo, either it isn't required!? or maybe that codec doesn't have full support??

I am currently trying something very slow to do. I have changed every layout for the ALC885 to ALC269 and am currently going through all of the associated pathmaps with the intention of changing just the nodeid's to ones that we use. The reason for so many layouts and pathmaps has got to be to account for the variations in all of the implementations Apple has done and some look like they just about match our layouts. Over in controller, I modified all of the associated layouts there (items 1,9,12,13&14) for the ALC885 to match our pinconfigs and the one that only has 2 pin configs (item 12) is to set the mic color and pindetect. I removed the pin detect verb for the SPDIF In since we don't have that and modified the mic jack in that was already there. I am hoping that maybe in all 25 of the layouts in Platform's plist that the ALC885 driver will match one of them up with the 269 once I am done. How it matches them up I have no idea. Subsystem id maybe?? If it is subsystem id, at least we can change that using a verb to anything we want. say something that matches a macbook? In any case, it's a long shot but what the heck else do I have to do this late at night, sleep?? bah!

Just for reference, here are all of the original layouts and their associated pathmaps for the ALC885 (283904133) in Platform's Info.plist

Layoutid    pathmap
12        9
16        8
36        16
38        20
42        15
44        16
46        17
48        17
50        17
52        18 - macbook?
53        26 - macbook?
54        22
56        16
58        17
60        17
62        17
63        42
64        43
65        25
66        40
67        41
69        41
70        41
72        41
16394    9

Edit: Actually, HDAEnabler has a field for LayoutID so you can probably use something other than 12. I think it just happens to be what people started using because it was the first one in the older AppleHDA.kext. EFI Strings should also allow using whatever layout id you want. Wouldn't it be much nicer if it just figured it the heck out ;)

Last edited on 1225267630|%e %b %Y, %H:%M %Z|agohover By Toonces + Show more

Re: AppleHDA.kext progress

snickersmd 1225268847|%e %b %Y, %H:%M %Z|agohover

Regarding HDAEnabler, I know you can change it, but whether you leave it at 12 or change it to 16 or 8 what I meant is that it will be statically hardcoded for that number, yet it seems that it probably changes around on a real Mac.

Also, I posted before that there may be a bug in the way HDAEnabler parses the plist, because when I tried to modify the layout id to 56, (hex 38) HDAEnabler loads the ASCII equivalent of what is in the plist instead. (in this case, ASCII 8) So, HDAEnabler does have limitations, albeit unintentional, as to the layout id that we can load.

Oh, and happy hunting with the brute force attack. That can't be fun. Necessary, perhaps, but never fun. ;)

EDIT: Here's another thought. If HDAEnabler locks it in to the values loaded, what if we don't use it to load any? What if we completely clear the plist, will it still load to allow detection of our device, but then let the driver have its way with layout ids and pin configs?

Last edited on 1225269234|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

Toonces 1225270897|%e %b %Y, %H:%M %Z|agohover

Actually, my HDAEnabler is already cleared. I did try to use just the pinconfigs but that didn't change anything. That could be because of the modified kext I am using with it though….

I am looking at these layouts and though they all have a codec id of ALC885, I haven't yet looked at one that matches an actual ALC885 yet. Granted I've only looked at pathmap 8 so far but the node id for the mic is way off. It correlates to the ALC885's Surround Sound out node. Are these pathmaps disguising chips that are not really 885's but present themselves to the HDA driver to pretend to be one??? The outputs on that pathmap look correct as does the line in input. It's just strange that the node id's are off. Why wouldn't they be the same? It's not like the 885 itself has different node configurations (other than you can use or not use whichever nodes you want). Does it? Can you redefine what each of the inputs and output of the 885 do??? If so that would explain a lot regarding all the different pathmaps.

EDIt: The answer is YES. The ALC885 is about as generic a sound chip you could want. every one of the 8 inputs or outputs can be either inputs or outputs. That really explains why all the layouts. If Apple wants to hook up node 0x16 as a mic, there's nothing stopping them from doing so and the chip will happily accommodate that. The ports that are fixed function are spdif in/out. Everything else will do whatever you tell it…..

Last edited on 1225293886|%e %b %Y, %H:%M %Z|agohover By Toonces + Show more

Re: AppleHDA.kext progress

hagglebeef 1225249746|%e %b %Y, %H:%M %Z|agohover

Codeye,

I have been avoiding doing anything to the Acer, because it needs a lot of work. I pulled it apart once already to put in 1GB DIMM and a 500GB 2.5" HD, but did not have the airport card at that time. Now I have both the airport card and USB hub, once I get going on it I will have tear it apart again and find the traces of a internal USB and start soldering the hub in for the missing bluetooth and non-working non-usb SD card slots for OSX to work. Maybe this weekend…

Re: AppleHDA.kext progress

codeye 1225326360|%e %b %Y, %H:%M %Z|agohover

hagglebeef,
sounds like it will be a very well "specked" machine when you finish!
i like everyone else has been hacking all variety of applehda derivations so that i often cannot remember what i've done!
but i think i am at the same stage as you at present. if i load all the verbs, from your alsa-driver dump or the realtek-patch, the codec dump it matches azalia and ubuntu (sets the correct amp settings, EAPD bits etc) - this is putting the verbs in controller.plist and just leaving enabler to load the kext up.
my codec dump however leaves out quite a bit of information (as does ubuntu codec#0) so it may well be other settings that are either not set correctly or are being overriden by the applehda.kext are the problem, when i get time i can make the program querry all the information in the codec, or you can do that yourself with the other verb_command utility.
i will look into this, but i am also going through the cotroller registers just to better understand how streams are fed into the codec on the working azalia system as i think that might be important (and interesting) - i'll let you know if i find anything.

Re: AppleHDA.kext progress

hagglebeef 1225329332|%e %b %Y, %H:%M %Z|agohover

Hi Codeye,

I got a hold of a copy of Mac OS X Internals. I am hoping that I can put together a kext that will live in between the generic codec driver and the AppleHDA and print out all of the verbs its sending to the alc269 like I did for the Linux alse driver. If it works, I can see if it is doing anything different. Wish me luck… :)

Re: AppleHDA.kext progress

snickersmd 1225331702|%e %b %Y, %H:%M %Z|agohover

hagglebeef,

Didn't you see my post on VerbSyringe? I proposed a similar project last night and was waiting for you and codeye to sound in. If you can code, then we can definitely get started!

Thread is here: http://ipis-osx.wikidot.com/forum/t-100783/verbsyringe-kext-a-possible-different-approach-to-the-applehda-mess

Guess it got drowned under all the other activity. :) As for seeing if the AppleHDA.kext is doing anything different, I could have answered that question. My look into the decompiled code of AppleHDA shows routines specific to each officially used AppleHDA chip, such that after codec ID, the sequence of verbs to send appears hardcoded. Your idea, of course, would show us exactly what is going on under the hood in real time.

Have you had a look into the decompiled code? I think it's on the wiki page.

Last edited on 1225332338|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

Toonces 1225336307|%e %b %Y, %H:%M %Z|agohover

Snickers, if the sequence of verbs is hardcoded then maybe we can change them to suit the 269?

I haven't looked at this yet but does this do what you are talking about? or maybe something like it? http://store.psystar.com/opensource/opendsdt

Re: AppleHDA.kext progress

snickersmd 1225340484|%e %b %Y, %H:%M %Z|agohover

That's actually one good approach that I thought about, but it has its drawbacks. We would be completely dependent on Apple code, as we would have to manually patch each updated kext as it would come along. More importantly, it would certainly have to wait until we have completely determined all the verbs that must be sent, compared against those that actually are sent.

The kext source you posted is interesting, it doesn't actually deal with registers the way Reggie does though… it looks like a way around needing a patched BIOS from Kabyl. If that works on the ipis and other netbooks, then we wouldn't need a patched BIOS to speed up boot.

Re: AppleHDA.kext progress

Toonces 1225342700|%e %b %Y, %H:%M %Z|agohover

Yeah, I don't really like that idea either :)

I figured it would get around needing kabyl's patched bios but in reading the short description I was wondering if it might let us mask our hardware as something it really isn't. In other words, could it make something like the ALC269 look like a valid ALC262 chip?? I have absolutely NO idea on it other than the short description that is there but it intrigued me as a possible way to masquerade the hardware into OSX thinking it was what it wants.

Re: AppleHDA.kext progress

snickersmd 1225348423|%e %b %Y, %H:%M %Z|agohover

I see what you mean. However, our problem isn't getting Mac OS to see a certain kind of chip, we already do that by patching the codec ID. Even if we dress the 269 as a 262, all that would accomplish is that Mac OS would send it signals intended for a 262, and as we're finding out, the 269 needs commands specific to itself.

I think we need to find the baseline commonality between all the codec chips (ala Azalia driver) then add on the commands that we're missing through an additional kext (taking over what we're doing now with Reggie) from that point on. Hmmm, would you happen to know off the top of your head if the 268to269 kext that they made the discoveries on is based on the 885 routine or the 262 routines?

Re: AppleHDA.kext progress

snickersmd 1225349391|%e %b %Y, %H:%M %Z|agohover

Every successful AppleHDA.kext hack before this has used the 885 routine set. In the 10/16 kext release I made, I chose to use the 262 routine set instead given the model number being in the same family as the 269.

However, as hagglebeef and codeye played around with my kext release, they kept hitting a brick wall. Furthermore, none of us, neither Toonces, nor I, have ever been able to find any reference to the 262 in layouts, plists, or anywhere else. It seems no one is even aware if Apple even has any hardware using the 262.

What if my kext has been wrong all along because of this tiny fact? What if the 262 routines were for a test or prototype that Apple never released? What if they don't even have complete coding behind them? After all, isn't it notable that everyone who has played with the newer MacBook update kexts has seen even more layouts for the 885? What if the 885 is the only Realtek codec in active development with advanced routines, and the 262 is merely in the code as a vestige or afterthought; legacy support if you will?

Here is the same kext I released on 10/16, only this time, invoking 885 routines instead of 262. If my missing routines/actively developed routines theory is correct, this kext may actually have better luck with verb injection than the previous one did (which isn't very much, for that matter).

http://ipis-osx.wikidot.com/local--files/forum:thread/AppleHDA.kext%203.zip

Re: AppleHDA.kext progress

madtux 1225351645|%e %b %Y, %H:%M %Z|agohover

Hi guys! Comatron told me to come here, when I told him that I am thinking of buying eepc1000, he said that this a great community, And what I see, U are realy working. This post is big, I don't know in what stage U guys are, if U need any help, I would like to get this sound working before I buy a eepc and give Lenovo to my sis

Re: AppleHDA.kext progress

snickersmd 1225357310|%e %b %Y, %H:%M %Z|agohover

madtux,

Welcome! You're already a sort of celebrity here, thanks to comatron and your InsanelyMac guide. :) I believe you will find our community has made very much headway into the deeper inner workings of the AppleHDA.kext, and some things you will find here you already know, and others will be new. I look forward to you sharing your expertise and experiences with us here to finally crack the AppleHDA.kext for full sound support. Please also visit the other project thread I have started here, the proposal for a "VerbSyringe" kext that will inject extra verbs as needed to control codecs that do not work right away with a patched AppleHDA.kext. Perhaps you will be able to lend invaluable help there as well.

Thank you for joining here, and on behalf of the whole community, I welcome you and we look forward to working with you.

Last edited on 1225357948|%e %b %Y, %H:%M %Z|agohover By snickersmd + Show more

Re: AppleHDA.kext progress

hagglebeef 1225365307|%e %b %Y, %H:%M %Z|agohover

madtux,

I would like to second the welcome. Mac OS X Internals is a hefty book, but I am getting some very useful information from it. Will start doing some coding later today.

Re: AppleHDA.kext progress

codeye 1225380716|%e %b %Y, %H:%M %Z|agohover

I think the state of play at present is,
We have sound working with azalia via headphones and speakers and therefore know that the corresponding nodes are set up correctly and can be manipulated by sending verbs as defined in alc269.pdf from realtek site or hdaudio_03.pdf from intel site - I have written a spaghettified program that allows you to run verbs and receive node output and a very slow program that will dump the entire codec (ala cat>/proc/asound/codec/codec#0 under linux) - verb_command_plus0.2 and codec_dump0.3 (both use the cli reggie_se).
elroy has a guide to getting azalia working and hagglebeef and others have written some scripts to help automate the process - basically azalia works out of the box with hdaenabler to load it under leopard and a verb command to switch the EAPD on (0x02) the pin complexes (0x14 speaker 0x15 HP) and mute or unmuting of the corresponding complex to switch between outputs.
thanks to hagglebeef we have the initialisation sequence (although I have taken this from patch_realtek.c)
<0083B000 00B37080 00B37180 00B37280 00B37380 0023B000 0033B000 00C37000 00C37100 00D37000
00D37100 00E37000 00E37100 01470740 015707C0 01670740 01870724 01970724 01A70720 01B70720
0143B000 0153B000 0163B080 0183B080 0193B080 01A3B080 01B3B080 01470100 01570100 02437000
02437180 02437280 02437380 01470C02 01570C02 01570101 02370105 0023B026 00837019 01270720
01870880 01570840 01570101 02370101 0023B026 0083701B 01270720 01870880 01570840>
that can be plugged in to controller.plist to correctly set the codec under applehda.kext and snickersmd has sorted the plist for autosensing between HP and speakers and the 2 mics (which are muxed) - I'm at present using a modified (but working on appropriate other hardware) 268 kext with autosensing (?10.5.2) to experiment with.
The lines of attack at present seem to be;
Snickers + Toonces - have good understanding of AppleHDA.kext and the decompiled binary and are looking further into tweaking this at the plist level and binary level to advance our understanding of the loading routines and possibly hardcoding initialisation of the codec if required.
Hagglebeef - gave us sound through azalia and also patched alsa-driver to help us understand how the software communicates with the codec under linux, is looking to do the same under OSX (this would be really cool!)
Codeye - I need to expand the codec_dump program to dump all the extra info on node 0 (and other nodes) with 0xF00 and parameters 0-0x13 that aren't already included, and anything else so that any differences between azalia.kext and our loading but non-functional appleHDA.kext are exposed. I'm also interested in playing with the controller registers to see if I can influence the streams under azalia and appleHDA as everything suggests the streams are being piped to the codec but maybe they are and somehow the codec isn't responding or is it being messed up at the controller level and not reaching the codec? - hard to tell.
Comatron/Madtux/anyone else - a simple fix to put us out of our misery, please? Or roll up your sleeves and hop on!

Re: AppleHDA.kext progress

madtux 1225394831|%e %b %Y, %H:%M %Z|agohover

Vendor Id: 0x10ec0269
Mic ATAPI: 0x12 (18), 0x23 (35), 0x08 (8)
Mic Jack: 0x18 (24), 0x23 (35), 0x07 (7)
IntSpeakers: 0x02 (2), 0x0c (12), 0x14 (20)
HP Jack: 0x03 (3), 0x0d (13), 0x15 (21)

How to HDA VERB based on 0269 Codec dump:
UNMUTE OUTPUTS AND INPUTS OF USING DEVICES:
"002"3B000 00237000 00237100
"003"3B000 00337000 00337100
"007"70100 00737000
00870100 00837000
UNMUTE AUDIO MIXER AND CHANELS AND MUTE ONE THAT U DON'T NEAD
"00b"37180 00b37280 00b37380 00b37480 00b37580
"00c"37000 00c37100 00c3B000
"00d"37000 00d37100 00dB000
"00e"37080 00e37180
"00f"37080 00f37180
FIX PINCTLS AND MUTE PINCOMPLEX(Pin Complexes are automatic unmuted thru Info.plist in Platform plugin):
"012"707"00" 0123B080
"014"707"40" 0143b080
"015"707"C0" 0153b080
"018"707"24" 0183B080
UNMUTE AUDIO SELECTOR FOR MIC
"023"37000 "023"37100 "023"37200 "023"37300
"024"37000 "024"37100 "024"37200 "024"37300
FIX EPAD DETECTION
"014"70C"02" "015"70C"02"
FIX UNSOLICITED_ENABLE
"018"708"08" "015"708"04"
FIX_SET_PROC_STATE
ENEABLE EAPD FOR POPS or fix control of eapd amp thru processing state NID (needed but it is better to test without it)
"020"701"00c"
"020"701"680"
ADD PINCONFIGVERBS
01271C10 01271D09 01271EA3 01271F99 01471C20 01471D01 01471E13 01471F99 01571C30 01571D40 01571E21 01571F01 01871C40 01871D98 01871EA1 01871F01 01D71C50 01D71D82 01D71E05 01D71F40
Without them in Leopard kexts u will have sound only thru speakers, in Tiger it can work without them but no SysProf.

I am uploading a test kext, so please can someone test it, and report back.
link removed

Last edited on 1225548381|%e %b %Y, %H:%M %Z|agohover By madtux + Show more

Re: AppleHDA.kext progress

nhirt 1225439789|%e %b %Y, %H:%M %Z|agohover

@madtux
When I try to download the file I get a "No servers are currently available…" message.
I would love to give it a shot. Could you please try to re-upload it somewhere else?

Thanks,

Nik

Re: AppleHDA.kext progress

Toonces 1225465186|%e %b %Y, %H:%M %Z|agohover

I get the same error message as nhirt. mediafire must have had some issues. I couldn't get anything at all last night from their site.

Re: AppleHDA.kext progress

madtux 1225478527|%e %b %Y, %H:%M %Z|agohover

removed by me.
go to post:
http://ipis-osx.wikidot.com/forum/t-94017/applehda-kext-progress#post-298015

Last edited on 1225547920|%e %b %Y, %H:%M %Z|agohover By madtux + Show more

Re: AppleHDA.kext progress

nhirt 1225482008|%e %b %Y, %H:%M %Z|agohover

Hi,

I downloaded and installed the two kexts in the zip but nothing changes. If I inject the known verbs with reggie_se it works as with Azalia.
Do I have to uninstall AppleAzaliaAudio.kext? I haven't done this yet (I just love having sound too much ;-). If ever, is it enough to delete the aforementioned kext and to clear the extensions cache?
What kind of info would you like us to determine with this test?

Nik

Re: AppleHDA.kext progress

strongesthylian 1225499965|%e %b %Y, %H:%M %Z|agohover

Installed the kexts from a fresh install of iDeneb. No sound devices appeared. System profiler shows the audio hardware, though. I tried injecting the verbs and nothing happened either.

Re: AppleHDA.kext progress

madtux 1225395420|%e %b %Y, %H:%M %Z|agohover

Codeye, where I can download your codec dump program, and does it works thru terminal? And do I need to go in single user mode to get work?

Last edited on 1225395482|%e %b %Y, %H:%M %Z|agohover By madtux + Show more

Re: AppleHDA.kext progress

comatron 1225400681|%e %b %Y, %H:%M %Z|agohover

yeah madtux is in the house. glad to see you here. thank you :) after 1348923823 reboots and tests now you got finally guys with some skill to deal with :D heheh keep the good work up!

Re: AppleHDA.kext progress

codeye 1225406690|%e %b %Y, %H:%M %Z|agohover

madtux,
the program files are found on the sound wiki page http://ipis-osx.wikidot.com/internal-sound. no need to run in single user mode but you need administrator privileges for the program to call reggie_se.

Last edited on 1225422547|%e %b %Y, %H:%M %Z|agohover By codeye + Show more

Re: AppleHDA.kext progress

comatron 1225407951|%e %b %Y, %H:%M %Z|agohover

yeah … there is a files link ant the bottom of the site ..

Re: AppleHDA.kext progress

Toonces 1225427102|%e %b %Y, %H:%M %Z|agohover

Welcome MadTux! I'll give your test kext a try tomorrow. Thursday is the kid's busy day so I've only been able to pop in for a few minutes at a time between band, gymnastics, cheer and band again. At least the blackberry gives me good speeds for connecting while I wait for one event to be done and the next one to start. Streaming Journey to the Center of the Earth from my slingbox (mac version now that we have sound!) to the eeeMac and tapping out a quick reply to the few threads I can. Anyways, Good to see you here. I'm looking forward to your contribution to our continued progress.

Re: AppleHDA.kext progress

toddgarvin 1225466475|%e %b %Y, %H:%M %Z|agohover

Just a quick question. Has anyone gotten the sound to work on a Lenovo S10 or is this only working on eeePC? Thanks!

Re: AppleHDA.kext progress

Diamondsw 1225467784|%e %b %Y, %H:%M %Z|agohover

a) If you did a search of this page, you'd see the answer is "yes".
b) This is a development page, not a support page.
c) You need to run the terminal commands on said support page.

Re: AppleHDA.kext progress

mega72 1225489094|%e %b %Y, %H:%M %Z|agohover

nobody has posted how to do this with a lenovo s10 yet, I've tried, no sound comes out of mine

Re: AppleHDA.kext progress

madtux 1225489669|%e %b %Y, %H:%M %Z|agohover

try the one 5 post before:
"Alternate link…"

Re: AppleHDA.kext progress

toddgarvin 1225511494|%e %b %Y, %H:%M %Z|agohover

Not working for me. Actually left me worse off. Before installing the kext files, I had sound showing in menu bar and working volume controls (just no sound). Now I have nothing. No output devices found. If I type "reggie_se" in terminal, I get ERROR: unknown processor type. I'm running on a Lenovo S10. So far, nothing from any of these posts has worked.

Re: AppleHDA.kext progress

Toonces 1225517305|%e %b %Y, %H:%M %Z|agohover

toddgarvin, when you look at About This Mac, what does it show for processor type there? If it shows an unknown type there then you should probably look at installing an alternate SMBIOS or SMBIOSEFI and correct that first. The kext MadTux posted was for testing and shouldn't require using reggie to activate but I would correct the unknown processor before going further.

Re: AppleHDA.kext progress

strongesthylian 1225523219|%e %b %Y, %H:%M %Z|agohover

toddgarvin,
The fact that you had sound before you installed MadTux's test kext means that you didn't remove the existing Azalia audio kext. Please remove it, then install the test kext, then report your findings.

Re: AppleHDA.kext progress

codeye 1225523292|%e %b %Y, %H:%M %Z|agohover

you will get unknown processor if you do not enter -D PhysAddr as a flag to CLI reggie_se and it will fail to run (the man page for reggie_se is typical Apple documentation - minimalistic to say the least!). Madtux's kext fails to load for me even without azalia and fixing permissions but no complaints in system logs, so not necessarily an azalia problem for toddgarvin.

Last edited on 1225523430|%e %b %Y, %H:%M %Z|agohover By codeye + Show more

Re: AppleHDA.kext progress

madtux 1225546554|%e %b %Y, %H:%M %Z|agohover

thx for testing, i believe the device detection is fixed now, it should show devices in SysPref, verbs are indentical.
Generic test 2:http://www.speedyshare.com/488450742.html
For EEePC users.
Test 2 noneepc:http://www.speedyshare.com/933251536.html
This is for non eeepc users, why is it different, well because PinConfig verbs for PinComplexes are not the same as in eeepc. And they block proper detection. But eeepc usr can test and this one if they like.

How to test:
Please remove azalia audio kext, or any efi audio string if u have.
install files from zip file
Open OSX86tools, check; Set Extensions permissions, Clear Extensions cache and Touch Extensions Folder
Reboot
If U have sound, well tell me
If not; try to use reggie_se fix and see will sound come from speakers

Re: AppleHDA.kext progress

Toonces 1225555148|%e %b %Y, %H:%M %Z|agohover

generic test 2 does same thing for me as generic test 1. No sound. Running my set_sound script to send the eapd verb gives an error "ERROR — Unaligned base address."

One thing that looks odd is that HDAEnabler appears to be loading twice according to console logs. There are no other errors in the logs. I verified that I only have the one copy of HDAEnabler installed. When I test I remove Azalia and my copy of HDAEnabler then set ownership & permissions on the 2 files provided in your archive and install them using kext helper.

11/1/08 8:25:52 AM kernel HDAEnabler: Copyright (c) 2008 by Kabyl 
11/1/08 8:25:52 AM kernel HDAEnabler: 05/05/2008 Added SPAudio support:Taruga 
11/1/08 8:25:56 AM kernel HDAEnabler: Copyright (c) 2008 by Kabyl 
11/1/08 8:25:56 AM kernel HDAEnabler: 05/05/2008 Added SPAudio support:Taruga

Additionally, the sound prefpane shows no input or output devices though I do have the ability to check the box to show volume control in menu bar. Volume controls themselves are grayed out and the Mute box is also checked.

IORegistry doesn't look like it has all of the device entries that previous AppleHDA.kext and Azalia have when they are loaded.

| |   +-o HDEF@1B  <class IOPCIDevice, registered, matched, active, busy 0, retain 8>
    | |   | | {
    | |   | |   "IOPCIResourced" = Yes
    | |   | |   "IOInterruptControllers" = ("io-apic-0","IOPCIMessagedInterruptController")
    | |   | |   "IOName" = "pci8086,27d8"
    | |   | |   "subsystem-id" = <1a830000>
    | |   | |   "IOPCIExpressLinkCapabilities" = 0
    | |   | |   "IODeviceMemory" = (({"address"=18446744073573990400,"length"=16384}))
    | |   | |   "layout-id" = <0c000000>
    | |   | |   "class-code" = <00030400>
    | |   | |   "IOPowerManagement" = {"ChildrenPowerState"=2,"CurrentPowerState"=2}
    | |   | |   "revision-id" = <02000000>
    | |   | |   "IOInterruptSpecifiers" = (<1000000007000000>,<0000000000000100>)
    | |   | |   "assigned-addresses" = 
    | |   | |     00: phys.hi: 8200d810 phys.mid: 00000000 phys.lo: f7eb8000
    | |   | |         size.hi: 00000000 size.lo: 00004000
    | |   | |         bus: 0 dev: 27 func: 0 reg: 16
    | |   | |         type: Mem flags: abs
    | |   | |   "built-in" = <00>
    | |   | |   "acpi-device" = "IOACPIPlatformDevice is not serializable"
    | |   | |   "device-id" = <d8270000>
    | |   | |   "vendor-id" = <86800000>
    | |   | |   "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/HDEF@1b0000"
    | |   | |   "subsystem-vendor-id" = <43100000>
    | |   | |   "name" = "pci8086,27d8"
    | |   | |   "IOPCIExpressLinkStatus" = 0
    | |   | |   "reg" = 
    | |   | |     00000000: 00 D8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 D8 00 02 00 00 00 00 00 00 00 00 ................................
    | |   | |     00000020: 00 00 00 00 00 40 00 00                                                                         .....@..
    | |   | |   "compatible" = <"pci1043,831a","pci8086,27d8","pciclass,040300">
    | |   | |   "Credits" = "2008 (c) Kabyl/Taruga"
    | |   | |   "PinConfigurations" = 
    | |   | |     00000000: 10 09 A3 99 20 01 13 99 30 40 21 01 40 98 A1 01 50 82 05 40                                     .... ...0@!.@...P..@
    | |   | | }
    | |   | | 
    | |   | +-o AppleHDAController  <class AppleHDAController, registered, matched, active, busy 0, retain 6>
    | |   |   | {
    | |   |   |   "IOProviderClass" = "IOPCIDevice"
    | |   |   |   "IOProbeScore" = 0
    | |   |   |   "CFBundleIdentifier" = "com.apple.driver.AppleHDAController"
    | |   |   |   "HDAConfigDefault" = ({"CodecID"=283902569,"ConfigData"=<0023b00000237000002371000033b00000337000003371000033b0000077010000737000008701000083700000$
    | |   |   |   "IOPCIPrimaryMatch" = "0x793a1002 0x437a1002 0x43831002 0x269a8086 0x26688086 0x27d88086 0x284b8086 0x026c10de 0x037110de 0x75021039 0x546110b9 0x3$
    | |   |   |   "IOMatchCategory" = "IODefaultMatchCategory"
    | |   |   |   "IOClass" = "AppleHDAController"
    | |   |   |   "IOPowerManagement" = {"CurrentPowerState"=2}
    | |   |   | }
    | |   |   | 
    | |   |   +-o IOHDACodecDevice@0  <class IOHDACodecDevice, registered, matched, active, busy 0, retain 6>
    | |   |     | {
    | |   |     |   "IOHDACodecVendorID" = 283902569
    | |   |     |   "IOHDACodecRevisionID" = 1048580
    | |   |     | }
    | |   |     | 
    | |   |     +-o IOHDACodecDriver  <class IOHDACodecDriver, !registered, !matched, active, busy 0, retain 5>
    | |   |       | {
    | |   |       |   "IOProviderClass" = "IOHDACodecDevice"
    | |   |       |   "IOProbeScore" = 0
    | |   |       |   "IOMatchCategory" = "IODefaultMatchCategory"
    | |   |       |   "IOClass" = "IOHDACodecDriver"
    | |   |       |   "CFBundleIdentifier" = "com.apple.iokit.IOHDAFamily"
    | |   |       | }
    | |   |       | 
    | |   |       +-o IOHDACodecFunction@1  <class IOHDACodecFunction, registered, matched, active, busy 0, retain 4>
    | |   |           {
    | |   |             "IOHDACodecFunctionSubsystemID" = 272859930
    | |   |             "IOHDACodecFunctionGroupType" = 1
    | |   |           }

EDIT: Forgot to add System Profiler Info.

Intel High Definition Audio:

  Device ID:    0x1043831A
  Audio ID:    12
  Available Devices:
  Microphone:
  Connection:    Internal
  Speaker:
  Connection:    Internal
  Headphone:
  Connection:    1/8 inch Jack
  Microphone:
  Connection:    1/8 inch Jack

EDIT2: An interesting side effect of loading this kext is that after I revert back to Azalia, I have to reboot twice before getting my audio back. I reboot using -v -f every time I load or replace kext in addition to using kext helper to do the loading. The first time I reboot then run my script to turn on EAPD for the speakers, there are no errors and the script completes normally but I get no sound. The second time I reboot and run the script I have my sound back.

Last edited on 1225556283|%e %b %Y, %H:%M %Z|agohover By Toonces + Show more

Re: AppleHDA.kext progress

madtux 1225557381|%e %b %Y, %H:%M %Z|agohover

toonces, Pinconfig data is injected, but now I know that 885 codec doesn't work with 269. So we nead to deal with sigmatel codec, funny thing that alc268 and 862 can work with 885(and hdaverbs)
Can U try this one:
http://www.speedyshare.com/806961393.html

Last edited on 1225558658|%e %b %Y, %H:%M %Z|agohover By madtux + Show more

Re: AppleHDA.kext progress

comatron 1225600511|%e %b %Y, %H:%M %Z|agohover

tested. noobish answer: amps are on (crackle on both ports). syspane gives me this time: 2 outputs (so no switching when putting hp in hp) - headphones & speakers. ONE mic (internal) in which does not work with internal/external mic.

sysprof gives me 4 devices: mic, mic & out out.

im drunk . but i tested as good as i can. im out …

Re: AppleHDA.kext progress

Toonces 1225604952|%e %b %Y, %H:%M %Z|agohover

I'll test it tomorrow madtux. I've been gone all day (UofA Band day) and just got home.

Re: AppleHDA.kext progress

Toonces 1225663398|%e %b %Y, %H:%M %Z|agohover

Hi MadTux, I have the latest AppleHDA.kext & HDAENabler.kext you wanted me to test installed. I get the proper devices in the sound prefpane and IOReg looks like it is correct (or at least it looks like it's all installed). No sound. I tried using my script to set EAPD on and it failed with "ERROR — Unaligned base address." so I loaded up one of codeye's reg tools and set EAPD on by manually sending the verb. I verified that EAPD is on for node 14 and I still get no sound. One thing I do notice, just as in many other attempts we've done, none of the mute controls are active. They're all grayed out and un-selectable. Could it be that even with he amps on, the volume is still muted?
Also, again it appears as if HDAEnabler is starting twice. There are no errors in the console log.

Console: