@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.
snickersmd 1222911474|%e %b %Y, %H:%M %Z|agohover
