—> http://thireus.dareyourmind.net/index.php/macos-apps/13-get-microphone-and-audio-in-working-on-your-eeemac

i just installed IPC 10.5.6 on my Asus 1000H but i cant get the sound working ? I did exactly whats written in the sound guide on this site but still no sound! Argh! Im desperate! Quick boot disabled, Apple.HDA removed, Audio enabled etc. But still no sound ? Anyone got sound working with IPC or should i switch to another distribution ?

Any help is appreciated!

Intel High Definition Audio:

Device ID: 0x1043834A
Audio ID: 662
Available Devices:

been messing with linux dumps and HDApatcher with no luck. This one however popped up after an install pack for a gigabyte motherboard with an alc662.

I've read that the chip is a few different things, but it seems if someone can put the 269 codec into a HDA kext it may work.

greetz okta

The Voodoo team now has an alternative implementation of AppleHDA. It is a FreeBSD port and has compatibility with probably 99% of codecs that are out there. Feature wise it is currently capable of outputting to both internal speakers and headphones. Recording via the internal microphone and microphone port is disabled in the build I have but has been completed.
We are going to be looking for some technically proficient testers (those that have actually been modifying AppleHDA and understand pin configuration and verbs) to confirm the extension works on hardware that has been unable to work well with AppleAzalia or AppleHDA. It seems from looking around the forums that EEE users have serious problems, i'd like to hear from any users here who meet the testing requirements so we can find out how well this new extension works.

Bear in mind that at this stage, Dense is requesting for testers that are technically proficient with pin configuration and verbs, so this is not ready for prime time with the part of the community that needs help using Audieee or the relative console commands. This basically means our existing HDA dev team (minus myself, until next year).

Very exciting stuff! I was not looking forward to disassembling AppleHDA further! :)

I just realized I posted this in the development forum, and probably should have posted in support.

Audiee: EeePC audio verb injector menu item

As a result of the awesome development work being done in these very forums, we've got a temporary fix for breaking EeePC's silence… Unfortunately not all of us here are all that fond of the using the terminal or, lets be honest, are just too lazy to bother with all that typing and, worse, having to remember stuff!

Audieee remembers your last setting (Headphones or Speakers) and reinstates that setting after sleep or when the app is relaunched after reboot.

What do I need?

First off you're probably best to have attempted to use some of the methods described in the 'quick and dirty' thread. But here's all you should really need:

• AzaliaAudio.pkg.zip
• Audieee 1.0.1
• Apple Devloper Tools (found on your purchased Leopard DVD)

What do I do?

• Remove AppleHDA.kext from your Extensions folder (System drive > System > Library > Extensions).
• Install the AzaliaAudio.pkg
• Reboot
• Install Apple Developer Tools (this is needed for ioreg and reggie_se - if there are other methods for installing these elements, feel free to comment below).
• Launch Audieee.
• Listen to things.

Troubleshooting

• Make sure you're running the stock (vanilla) kernel
• Make sure that audio is enabled in your eeepc's bios

If Audieee still doesn't work 'as advertised' then use the Q&D Thread for troubleshooting BEFORE posting problems in this thread. If you can't turn sound back on via the commands shown in that thread, then Audieee isn't going to work for you until you can. Audieee is just a front end for those same commands.

UPDATE version 1.0.1

• Audieee now runs without a dock icon
• Various 'About Dialogue' bug fixes

Anything else?

You can add Audieee to your Login items to save having to launch it manually after reboot.

Please report back your results as it will help others work out any problems that they may run into.

Audieee was created by Jamie Curmi using parts of QuinnStorm's script (with permission). All i did was slap together the app icon… not bad for a guy with two stitched up eyes… at least as far as I can tell.

PS: This is the only place that Audieee has been released. Feel free to tell others about it, but in an effort to help gather the EeePC/OSX community together please link directly to this thread and not to the file itself. Thanks.

of course in both cases 0x01470c02 (enable EAPD on NID 0x14) must be issued separately to get sound going.

Next a dump of a non-working AppleHDA.kext

So I went back to the decompilation I made of the 10.5.5 AppleHDA.kext. First of all, all of the mystery plist settings are actually there and it became evident that we could simply use a disassembly to figure out what MuteGPIO and all that other stuff actually means on Apple's terms.

But before I even did that, I started poking around even deeper into the code. Why does it seem that Apple isn't switching on the EAPD for us on the ALC269? Does the driver not know to do that? Of course not, there's actually a routine for it in the code as well. So why isn't it being called for the nodes that need it?

The answer is in another of Toonces' contentions that the AppleHDA driver is becoming more specialized, as opposed to my theory that they simply should become universal as more and more chips are supported. Sure, in the AppleHDA binary there is reference to a section of code called AppleHDAGenericCodec, but that's because thanks to the Intel HD Audio Spec, the interface to codec itself is generic, but what Apple does with it is totally specific and driver contained.

This is my revised interpretation to what is going on in the code. Please remember that I am not a programmer, have no internal knowledge of what Apple is really doing, and that this is all speculation on my part. Apple has programmed a reusable code block, the GenericCodec, through which it communicates with the Intel HD Audio Codec. On top of that, there are specialized routines, one for each codec chip used, to initiate vendor specific codes for any given codec chip (Realtek, Stac, etc). As far as we are concerned with the Realtek codecs, these would be the 885 and the 262. After this, Apple uses the plist to make implementation or model specific changes to account for how each of their hardware systems actually uses the codec chip and the different modes it can be placed in.

Assuming this is a valid interpretation, why then has the driver been successfully hacked to accommodate other codec chips? I think the answer is luck. Apple didn't intend it, it just so happens that Realtek made it so that most of their chips respond the same way to the same commands. So by hacking AppleHDA.kext and tinkering with the plists, we get the driver to send ALC885 commands to an ALC880 or an 882 or so on, and the 880 just responds because it understands.

So what happens when Realtek puts out a different chip that does not conform in the same way? Or the vendor does something different with it such that you need to issue it other commands before it will work? We know the 269 is different enough that the ALSA driver needed patches to its source code just to work with it. I think that's where we are today with the more advanced AppleHDA.kext. Extra verbs need to be sent, but unlike in Windows, where the UAA driver actually asks the chip, hey what do you need, and then sends it so that it will work, the AppleHDA driver never bothers. It says, hey, if you're not ready after I'm done initializing, well that's your problem. From that point, I think plist manipulation can only bring you so far.

I doubt this is by design; I mean, I don't think Apple is deliberately trying to foil usage of their driver on other hardware. I'm not a fanboy but it just doesn't make sense for a company that produces the only commercial desktop operating system that doesn't require any Activation mess or CD-Key to actively invest in coding countermeasures within the operating system itself. Rather, I think it's just that it would add an extra layer of complexity to their driver code to make UAA style queries, and so they stick with the more stable approach of hard-coding the needed routines. Regardless of Apple's actual intent, we're still no closer to a true driver solution with what they've given us.

Which brings me to my new proposal. The exciting discoveries of verb manipulation show much promise. Of course, we still need to figure out why verb injection doesn't seem to work in the newer AppleHDA kexts while it does in the older kexts and Azalia. In the meantime, the whole mess of needing Reggie and writing scripts and third party sleep routine programs works but it isn't pretty. What we need is a kext.

I propose to code a kext and call it VerbSyringe. What it would do is load up, identify the audio kext loaded, take the correct memory address from the audio kext/IORegistry, and then, based on a documented plist format that we control, injects needed verbs depending on the audio chipset. This way, such a kext could be coded, and it wouldn't matter whether you were using the Azalia driver or the AppleHDA driver — it would be independent, like HDAEnabler is now. Being a kext, we could also stick a routine in there to be included in power management, so that verbs could be sent automatically on wake and reboot, etc. The best part is that if coded properly, we could use a plist to support more than just the ALC269 and basically be future-proof until the ALC300 comes out ;).

A truly useful feature would be to also incorporate HDAEnabler's job, and also make in-memory patches to the HDA Driver so that even the newer ones act like the older Azalia driver with basic, generic routines. If this could be accomplished, then you wouldn't even need to patch AppleHDA kext or its plists, you would only need to install VerbSyringe.

Now, I've never coded a kext before, but I've started reading up and it seems well documented enough, and a kext that simply modifies registers doesn't have to be very complex. What it truly would do is free the end user from having to use scripts or have Reggie installed on their computer or have to enter super user mode for any reason.

Thoughts? Do you think this would be a viable project with practical application? Any pitfalls that I have overlooked? How should we go about doing it? and lastly, volunteers anyone? :)

This guide assumes that you are familiar with installing kext files (either 'by hand' / using the terminal / or via an application like Kext Helper).

Required Files:

Hagglebeef modded kexts (potentially unneeded, please leave feedback as per codeye's request)
http://rapidshare.com/files/157602713/eee901kext4sound.zip.html

AzaliaAudio.pkg.zip (i've not personally tested this source).
http://www.mediafire.com/?enez1guzz1g

Instructions:

1. Install the AppleHDA.kext from the AppleHDA269from268 folder in Hagglebeef's zip (potentially unneeded, please leave feedback as per codeye's request)
2. REBOOT
3. Run the AzaliaAudio installer
4. REBOOT

If sound goes down with sleep or reboot run the following commands (please change the memory address to that found in Ioregexplorer for your eeepc - mine (codeye's) is 0xf7db8000 EEEPC901) - You need to have reggie_se installed from the developer tools:

This sets the verb command to turn EAPD on for the speaker Pin Complex:

 sudo reggie_se -D PhysAddr -w 0x01470c02 -a 0xf7db8060 -B 32 

This sends the verb command to the codec:

 sudo reggie_se -D PhysAddr -w 1-a 0xf7db8068 -B 32 

None of the content of this guide is my doing, all credit belongs to the guys mentioned above, and those who have helpfully participated in the original thread.

Cheers

Taken from the platformdriver-stock.plist:
Root/IOKitPersonalities/HDA Platform Resource/Layouts/6/PathMapRef/0/Headphone/MuteGPIO 1342242840

This value seemed to go through without taking 10 minutes to boot.
No sound.

Any suggestions?

-GReg

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!

i sold my macbook recently in order to move to ultra-portable and so far this is my favorite machine but without sound i am at a lost because i sooooo want to keep this one.

i currently have:

-Aspire One w/ 250GB and 1.5GB RAM which runs iATKOS v4i very well but is a loser to me because i now like the larger screen and 6 cell battery life. so this one is going to go. nice machine but i like the 1000h much better for the keyboard, screen, battery life, and touch pad. i can get a 6cell for the Aspire but having now used the 1000h i can't go back.

- 1000h can't complain about anything except for sound and i sadly dont see it getting fixed.

- MSI WIND and it just works. i replaced the wifi card with an apple N wireless card and although i dont want to this to be my decision i may have to lean this way because it has sound.

i am hoping that a sound fix will be found before i pick one of these and sell the others.