[HOW TO] Patch AppleHDA - Knowledge Base

[SMF]

cparm,

 

Thanks. I'm understanding a bit more and my dsdt_fixed has the same AZAL section. Now I just need to understand what you've added to the _DSM section. Do you use the stock AppleHDA.kext or a modified one?

 

Thanks,

SMF

[macgirl]

iasl -ta /path to/dsdt_fixed.txt

 

this will create your dsdt.aml file in the debug folder, and then just put it to your root directory

 

@macgirl: even with this patch i need the efi string audio part otherwise the appelhda kext don't load, same thing with the dsdt.aml generated by the the fassl patcher

 

@macgirl: i have the same issue with the system profiler on the graphic section, i don't know why ????, but my CG work fine with QE/CI, maybe the last version of the patcher (1.0.1e) will fix this

Hey, thanks, it worked

 

I did my dsdt with 1.0.1e Graphics section do not crash with it, I think I read something about it.

[cparm]

cparm,

 

Thanks. I'm understanding a bit more and my dsdt_fixed has the same AZAL section. Now I just need to understand what you've added to the _DSM section. Do you use the stock AppleHDA.kext or a modified one?

 

Thanks,

SMF

 

for now, i still use moded applehda, but the legacy method seems to be able to load vanilla applehda (not tested yet)

[roidm]

I´ve changed

 

 Notify (\_SB.PCI0.AZAL, 0x02)
...
...
...

Device (AZAL)

 

Notify (\_SB.PCI0.HDEF, 0x02)
...
...
...

Device (HDEF)

 

with this the system loads fine the stock AppleHDA.kext (ALC889a) with efi strings... I´m trying to inject those values

 

 Device (HDEF)
				{
					Name (_ADR, 0x001B0000)
					Method (_PRW, 0, NotSerialized)
					{
							Return (Package (0x02)
							{
								0x0D, 
								0x05
							})
					}

		Method (_DSM, 4, NotSerialized)	
			{				
				Store (Package (0x08)
					{
						"codec-id",
						Buffer (0x04)
						{
							0x89, 0x08, 0xec, 0x10
						},

						"layout-id",
						Buffer (0x04)
						{

							0x0c, 0x00, 0x00, 0x00
						},

						"device-type",
						Buffer (0x011)
						{
							"ALC889a"
						},

						"PinConfigurations",
						Buffer (0x20)
						{
							 /* 0000 */   0x50, 0x70, 0x21, 0x01, 0x40, 0x01, 0x13, 0x90, 
							 /* 0008 */   0x20, 0x30, 0x81, 0x01, 0x41, 0x40, 0x01, 0x01,
							 /* 0010 */   0x30, 0xe0, 0xc5, 0x01, 0x60, 0xe0, 0x45, 0x01,
							 /* 0018 */   0x0f, 0x00, 0x00, 0x40, 0x0f, 0x00, 0x00, 0x40,
							 /* 0020 */   0x10, 0x01, 0xa0, 0x90, 0x11, 0x01, 0xa0, 0x90 
						}

					}, Local0)
				Return (Local0)		
			}	
		}

 

but i get a lot of errors when i compile the dsdt

 

edit: my codec-id was wrong , it must be 10ec0889

[cparm]

No success here (GA EP35 DS3R with ALC889a).

I think my pin configuration values are maybe wrong:

IOregistryExplorer:

<10 44 11 01 20 14 01 01 40 4c 21 02 50 34 81 01 60 9c a1 02 f0 61 4b 01>

dsdt.dsl:

Buffer (0x18)
						{
							/* 0000 */	0x10, 0x44, 0x11, 0x01, 0x20, 0x14, 0x01, 0x01,
							/* 0008 */	0x40, 0x4C, 0x21, 0x02, 0x50, 0x34, 0x81, 0x01,
							/* 0010 */	0x60, 0x9C, 0xA1, 0x02, 0xF0, 0x61, 0x4B, 0x01

Codec id does not appear in IOregistryExplorer, but assuming System profiler informations, Codec id is:

So it should be:

"codec-id",
						Buffer (0x04)
						{
							0x14, 0x58, 0xa0, 0x02

I'm using plist method with stock HDA.kext.

 

@cparm: should i remove the AZAL entry onto dsdt.dsl or just add HDEF?

 

this value : 0x1458A002, is not your codec id,

 

with the ACL889a your codec id is 0x10ec0889, so this section should be:

 

"codec-id", 
						Buffer (0x04)
						{
							0x89, 0x08, 0xec, 0x10
						}

 

, you can leave the azal entry, but i think it's depend on the efi part

 

i mean if you the command gfxutil -f HDEF work and give a devicepath, you should edit/add a hdef entry to your dsdt

 

if gfxutil -f AZAL work, try first to edit the dsdt azal entry

 

@roisoft, try to not change anything, just add the hdef entry to your dsdt

 

ps 1: i think, your codec id is wrong, 0x0000293e is the device-id, your codec-id is 0x10ec0889

ps 2 : what kind of error ?

[cparm]

Hey, thanks, it worked

 

I did my dsdt with 1.0.1e Graphics section do not crash with it

 

confirmed

[cparm]

I´ve changed

 

 Notify (\_SB.PCI0.AZAL, 0x02)
...
...
...

Device (AZAL)

 

Notify (\_SB.PCI0.HDEF, 0x02)
...
...
...

Device (HDEF)

 

this method work fine, but it still can't load a stock applehda

 

my new dsdt.aml and dsdt_fixed.txt for GA-P35-DS3L rev2

[THe KiNG]

this method work fine, but it still can't load a stock applehda

That is b/c we still dont know how the hell to inject the rest of missing info for hdacontroller and platformdriver

I'm n00b on programming, maybe someone can make a kext to inject/overwrite these info on vanilla hda plists like BuildSmart did for badaxe2...

Someone offer?

[kramer2k]

Just an FYI, I've almost got the P31-DS3L worked out. I only have output via front headphone audio jack though... But it's progress!

 

I'm getting an error in console at startup listed multiple times...

 

11/21/08 12:15:42 AM kernel Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAWidget.cpp" at line 1341 goto handler

 

Any additional help would be appreciated...

codec_dump.txt

Numbers.txt

[cparm]

Just an FYI, I've almost got the P31-DS3L worked out. I only have output via front headphone audio jack though... But it's progress!

 

I'm getting an error in console at startup listed multiple times...

 

11/21/08 12:15:42 AM kernel Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-157.1.24/AppleHDA/AppleHDAWidget.cpp" at line 1341 goto handler

 

Any additional help would be appreciated...

 

try my applehda, it's for p35-ds3l, but the pin configuration seems to be the same

[kramer2k]

I thought I looked at yours and saw that the pin configs were different...I'll have another look at it later tonight.

[cparm]

I thought I looked at yours and saw that the pin configs were different...I'll have another look at it later tonight.

 

the configdata string inside the applehdacontroller is moded, so it's not my original one,

 

but look at my codec dump, it's really the same

 

 

 

 

[kramer2k]

Woot! Your kext with my pin configs works great...but no like you said, no front headphones...

 

but how do you enable 5.1? Do you need to have 5.1 speakers plugged in to be able to configure it?

[cparm]

Woot! Your kext with my pin configs works great...but no like you said, no front headphones...

 

but how do you enable 5.1? Do you need to have 5.1 speakers plugged in to be able to configure it?

 

this is because i have removed all front port, so only the back panel work for now, but i'm working on the grey port and the font headphone:

 

Blue: set to Line In - Working

Green: set to Line-out - Working

Pink: set to Mic In - Working

Black: set to IntSpeaker - Working

Orange: set to Headphone - Working

Gray: -Removed - Work in progress

 

S/P-DIF In: - working - not tested

S/P-DIF Out: - Working - not tested

 

Front: Headphones -Removed- Work in progres

Front: Mic In -Removed- Work in progress

 

but how do you enable 5.1? Do you need to have 5.1 speakers plugged in to be able to configure it?

for analog 5.1,

 

first, play a music with itunes for exemple, and swicth between Line-out, IntSpeaker and Headphone in the sound preferences,

 

when you choose line-out, put the jack of you speaker in the green port

when you choose heaphone, put the jack of you speaker in the orange port

when you choose intspeaker, put the jack of you speaker in the black port

 

if all port give you sound, this mean 5.1 will work with an aggregate device

 

see the Consolation Guide, to know how to set it

[Taruga]

should i give some time with 1998B or it's worthless?

i don't know about progress so far, taruga wiki is down a long time

 

 

Use this file for AD1988b I´ve patched some months ago for a Asus P5K-E , should work with yours also.

[Taruga]

@Taruga

 

hi Taruga, i'm happy that you are back

 

 

I´m not really back yet, I can´t push myself too much, I´m still recovering and I´m on sick leave on my 3rd month now. I mostly try to watch the osx community evolution and news, watch tv and rest as must as possible.

I can´t at the moment help anyone unless with things I have ready done in the past. The pills I´m taking don´t allow me much more, I have no strength or mental patience to do much more than rest and watch tv. My site is off ( I know), it will be back on when I get better and return to work since I have there a full backup. I think that maybe from 20 December forward that will happen. Maybe I´ll think about a mirror site to avoid down times since my hosting provider really sucks and they gave me a lot of warnings and even a 'last warning'.

 

Today makes a week that I finally have strength on my legs and the pain is gone and I can walk. So, things are getting better physically. On the mental side, I´m still suffering from some pill side effects by I think that by late December I will be fine and ready.

 

I´ll keep in touch when possible, but please don´t ask me solve any problems now since I have my own problems to solve first. I hope you understand.

[Taruga]

One advice to people with curiosity in audio and PinConfigurations, there is no need to setup them up on DSDT (do it if you want to). I just changed AZAL to HDEF and I used a couple of plists for AppleHDA to send the correct verbs to the audio codec.

PinConfigurations also knows as codec verbs are used and sent when AppleHDA establishes a link to the audio codec. And that happens with AppleHDAController, I don´t see a way of DSDT editing to make some miracles I did with some codecs, like 1988b, alc861, etc... Most of them use special codec verbs to do other audio codecs setups. You can get the idea with alsa source of from some xp and vista drivers that come with codecs verbs that not only set pin configs right but also enables sound on some muted systems.

PinConfigurations are a small part of all the Codec Verbs Power !!!

If the codec verbs are set right on AppleHDAController info.plist even the PinConfigurations will be filled out if it´s property value is empty.

As I said before, I don´t think AppleHDA will be the solution for ever and for all. That is way I started coding some months ago a generic HD Audio Driver that will not need any messy plists. AppleHDA was made only with some codecs in mind and can give a lot of different problems with some chipsets and audio codecs. Maybe I´ll release a more 'smart' patcher that one click does it all or maybe I´ll just continue what I was working on before I got sick, the generic 'smart' audio driver to replace AppleHDA. Most sound issues will continue without a proper driver made for PC's in mind. I think most of you will agree with what I´m saying. Why most recent Realtek codecs work and some others ? Because they are very similar in pin nids, mixers, adc´s and dac´s and AppleHDA supports some of them with some changes. AppleHDA is always changing and things gets more hard to fix. Motherboard chipset incompatibilities, audio codecs not totally supported by AppleHDA, etc....

 

Since I´ve started my own sound driver I realized most of the problems and issues I expect (and will expect) in the present and future with AppleHDA.kext. Even the last months before I got sick, while testing on 3 different chipsets and audio codecs I got several issues to take in consideration because the driver behaved different on the three chipsets ICH7 with ALC882, ICH8 with AD1988b and ICH9 with ALC889a. This a very complex and time consuming driver and I have no estimated date for release. The driver will have lots of additional stuff and will work will real macs also.

I just hope I recover well and can continue working on it, it would be a shame to loose all the time I spend coding it until a few months back.

 

I don´t know if any of this makes sense to any of you guys, also, I´m too drugged to think right and maybe my point of view, informations and suggestions don´t make much sense. My head is still a little screwed up at the moment.

 

I think all the info is welcome and I think I´m helping with this post on something....I hope.

[kramer2k]

@cpram

No dice my friend...I only get output on Rear Green output. Nothing on Black or Orange. And I can set it up to be 5.1, but again Green's my only friend...

 

See screenshots...there, but just no output...

 

 

@Taruga - Welcome back and I can only wish you a speedy recovery!

[ac3bcn]

Hi Everyone, I find this information at Realtek Homepage, from ALC889a Datasheet, here's the link

 

http://www.realtek.com/downloads/downloads...;Downloads=true

 

a pair of screenshots for Verbs, Pin Configuration and Nodes.

 

I think it could help us to determinate Pathmaps,ConfigData, etc for ALC889a.

 

Here it is.

[SMF]

I didn't see this posted elsewhere on Insanelymac and hopefully this will help us figure things out -

 

Here's a codec dump from a new MacBook made using Mandriva Linux.

 

SMF

New_MacBook_Codec_Dump.txt

[THe KiNG]

I´m not really back yet, I can´t push myself too much, I´m still recovering and I´m on sick leave on my 3rd month now. I mostly try to watch the osx community evolution and news, watch tv and rest as must as possible.

I'm very happy that you are OK and making progress on recovery

I hope soon you can help me to finish(as much is possible) this guide since is based more then 80% on your work.

One advice to people with curiosity in audio and PinConfigurations, there is no need to setup them up on DSDT (do it if you want to). I just changed AZAL to HDEF and I used a couple of plists for AppleHDA to send the correct verbs to the audio codec.

PinConfigurations also knows as codec verbs are used and sent when AppleHDA establishes a link to the audio codec. And that happens with AppleHDAController, I don´t see a way of DSDT editing to make some miracles I did with some codecs, like 1988b, alc861, etc... Most of them use special codec verbs to do other audio codecs setups. You can get the idea with alsa source of from some xp and vista drivers that come with codecs verbs that not only set pin configs right but also enables sound on some muted systems.

PinConfigurations are a small part of all the Codec Verbs Power !!!

If the codec verbs are set right on AppleHDAController info.plist even the PinConfigurations will be filled out if it´s property value is empty.

As I said before, I don´t think AppleHDA will be the solution for ever and for all. That is way I started coding some months ago a generic HD Audio Driver that will not need any messy plists. AppleHDA was made only with some codecs in mind and can give a lot of different problems with some chipsets and audio codecs. Maybe I´ll release a more 'smart' patcher that one click does it all or maybe I´ll just continue what I was working on before I got sick, the generic 'smart' audio driver to replace AppleHDA.

.....

Since I´ve started my own sound driver I realized most of the problems and issues I expect (and will expect) in the present and future with AppleHDA.kext. Even the last months before I got sick, while testing on 3 different chipsets and audio codecs I got several issues to take in consideration because the driver behaved different on the three chipsets ICH7 with ALC882, ICH8 with AD1988b and ICH9 with ALC889a. This a very complex and time consuming driver and I have no estimated date for release. The driver will have lots of additional stuff and will work will real macs also.

I just hope I recover well and can continue working on it, it would be a shame to loose all the time I spend coding it until a few months back.

........

I think all the info is welcome and I think I´m helping with this post on something....I hope.

About DSDT, I posted that trick keeping in mind the future Snow Leopard, and as I mentioned this step can be done only if the sound works 100% and patching hda on that codec is closed subject. You are right about AZAL->HDEF, in my case was HDAC or on my desktop was no entry for sound in DSDT so I added HDEF entry.

I still didn't figured out a way to replace the hdacontroller and hdaplatform plists on the fly w/o those ugly dependencies errors on boot or how to inject them using DSDT.

I did some research on my other board(P5K3 Deluxe ICH9R) with AD1988b using same method, so far I got 5.1 analog out and anemic mic in w/o volume controll on it and digital in/out(not tested). I didn't have much time to play with it since my focus is on my lappie(notebook's as far more PITA)

 

I agree that a dedicated driver is the best solution, I heard that other dev's are doing something on porting/writing a new driver, but until then we still have to mess with HDA..and get how much is possible from it, and that was the main reason for me to write this guide since is impossible for 1-2 people to fix so much codecs on so many configurations...

 

I hope you will recover soon.

[THe KiNG]

http://helllabs.org/codecgraph/ doesn't work (((

 

Could anyone upload codecgraph here ?

 

Cheers.

Here it is: Codecgraph & ConvertHexToDec.rb

I hope the reason for site down is for update ...

[Guest BuildSmart]

One advice to people with curiosity in audio and PinConfigurations, there is no need to setup them up on DSDT (do it if you want to). I just changed AZAL to HDEF and I used a couple of plists for AppleHDA to send the correct verbs to the audio codec.

PinConfigurations also knows as codec verbs are used and sent when AppleHDA establishes a link to the audio codec. And that happens with AppleHDAController, I don´t see a way of DSDT editing to make some miracles I did with some codecs, like 1988b, alc861, etc... Most of them use special codec verbs to do other audio codecs setups. You can get the idea with alsa source of from some xp and vista drivers that come with codecs verbs that not only set pin configs right but also enables sound on some muted systems.

PinConfigurations are a small part of all the Codec Verbs Power !!!

If the codec verbs are set right on AppleHDAController info.plist even the PinConfigurations will be filled out if it´s property value is empty.

As I said before, I don´t think AppleHDA will be the solution for ever and for all. That is way I started coding some months ago a generic HD Audio Driver that will not need any messy plists. AppleHDA was made only with some codecs in mind and can give a lot of different problems with some chipsets and audio codecs. Maybe I´ll release a more 'smart' patcher that one click does it all or maybe I´ll just continue what I was working on before I got sick, the generic 'smart' audio driver to replace AppleHDA. Most sound issues will continue without a proper driver made for PC's in mind. I think most of you will agree with what I´m saying. Why most recent Realtek codecs work and some others ? Because they are very similar in pin nids, mixers, adc´s and dac´s and AppleHDA supports some of them with some changes. AppleHDA is always changing and things gets more hard to fix. Motherboard chipset incompatibilities, audio codecs not totally supported by AppleHDA, etc....

 

Since I´ve started my own sound driver I realized most of the problems and issues I expect (and will expect) in the present and future with AppleHDA.kext. Even the last months before I got sick, while testing on 3 different chipsets and audio codecs I got several issues to take in consideration because the driver behaved different on the three chipsets ICH7 with ALC882, ICH8 with AD1988b and ICH9 with ALC889a. This a very complex and time consuming driver and I have no estimated date for release. The driver will have lots of additional stuff and will work will real macs also.

I just hope I recover well and can continue working on it, it would be a shame to loose all the time I spend coding it until a few months back.

 

I don´t know if any of this makes sense to any of you guys, also, I´m too drugged to think right and maybe my point of view, informations and suggestions don´t make much sense. My head is still a little screwed up at the moment.

 

I think all the info is welcome and I think I´m helping with this post on something....I hope.

First, sorry to hear of your ill-health and hoe you make a speedy recovery.

 

None of this shows any working audio with sigmatel STAC9274D or STAC9221D-A2 (or other common sigmatel chipsets).

 

What I do know is DSDT can provide data to not only the device but to drivers that load so claiming that DSDT modification is pointless or has little validity makes no sense.

 

You modify plist file data to make audio work, DSDT can supply the modified data so plist modification is not required so how can you say that this isn't useful or wont make any difference?

 

The fact that I work from limited data is the reason to obtain a working solution in the chipsets I do have so I can work it into DSDT and the failure to have one is the delaying factor in advancement of audio.

 

For me, the issue at hand before a full working DSDT solution can be provided is to be able to have a working sigmatel audio that is nothing more than plist modification and not one person has been able to show it despite the claims to have achieved this at some time.

 

I can't work on audio I don't have and while some have claimed to make audio for sigmatel work by plist modification, there is always some underlying excuse why it cannot be shown now.

 

Once a working solution has been provided for the sigmatel audio I do have, it can then be moved to DSDT and then allow progress for other sigmatel audio chipsets and even into ALC8xx (which I understand requires less work to make work natively) but I can't/wont spend the time making audio for a chipset I don't have work cause I have no way of testing it and relying on someone else with limited knowledge to test the work is difficult at best because anyone with knowledge/experience to figure some things out with a faulty boot caused by a mistake has better things to do with their time than to be on call to test potential solutions on-demand.

[THe KiNG]

None of this shows any working audio with sigmatel STAC9274D or STAC9221D-A2 (or other common sigmatel chipsets).

I did some tests on Sigmatel and what I can tell is that is possible to make it working!

AFAIK is hard for me to do it w/o that hardware(require lots of tests...)

Here is an example on what I did so far:

Codec: SigmaTel STAC9228
Address: 0
Vendor Id: 0x83847616
Subsystem Id: 0x10280209
Revision Id: 0x100201

Node 0x0a pin default 0x0221101f - [Jack] HP Out at Ext Front
VERBS 00a71c1f 00a71d10 00a71e21 00a71f02 
Node 0x0c pin default 0x90a79130 - [Fixed] Mic at Int N/A
VERBS 00c71c30 00c71d91 00c71ea7 00c71f90 
Node 0x0d pin default 0x90170110 - [Fixed] Speaker at Int N/A
VERBS 00d71c10 00d71d01 00d71e17 00d71f90 
Node 0x0e pin default 0x02a79130 - [Jack] Mic at Ext Front
VERBS 00e71c30 00e71d91 00e71ea7 00e71f02 
Node 0x0f pin default 0x0227011f - [Jack] HP Out at Ext Front
VERBS 00f71c1f 00f71d01 00f71e27 00f71f02 
Node 0x13 pin default 0x90a60040 - [Fixed] Mic at Int N/A
VERBS 01371c40 01371d00 01371ea6 01371f90 
Node 0x21 pin default 0x01442070 - [Jack] SPDIF Out at Ext Rear
VERBS 02171c70 02171d20 02171e44 02171f01 
Node 0x22 pin default 0x40f000f6 - [N/A] Other at Ext N/A
VERBS 02271cf6 02271d00 02271ef0 02271f40 

<00a71c30 00a71d40 00a71e21 00a71f01 00d71c40 00d71d01 00d71e10 00d71f90 00f71c20 00f71d10 00f71e21 00f71f01 02171c60 02171d01 02171e41 02171f01 00e71c50 00e71d90 00e71ea1 00e71f01 00c71c10 00c71d01 00c71ea0 00c71f90 02271cf0 02271d11 02271e56 02271f10>

Sigmatel and/or other codecs can be fixed using right verbs and plist's

 

What I do know is DSDT can provide data to not only the device but to drivers that load so claiming that DSDT modification is pointless or has little validity makes no sense.

Can you explain/show how?

 

For me, the issue at hand before a full working DSDT solution can be provided is to be able to have a working sigmatel audio that is nothing more than plist modification and not one person has been able to show it despite the claims to have achieved this at some time.

 

Once a working solution has been provided for the sigmatel audio I do have, it can then be moved to DSDT and then allow progress for other sigmatel audio chipsets and even into ALC8xx (which I understand requires less work to make work natively) but I can't/wont spend the time making audio for a chipset I don't have work cause I have no way of testing it and relying on someone else with limited knowledge to test the work is difficult at best because anyone with knowledge/experience to figure some things out with a faulty boot caused by a mistake has better things to do with their time than to be on call to test potential solutions on-demand.

[Guest BuildSmart]

Funny but you were one of the ones who said you made it work at one time with sigmatel and now you offer generating the PinConfiguration data as a partial solution, that isn't a working solution and as a stop gap I already export the PinConfiguration from DSDT using the 10.4 modified AppleHDA.kext until a solution becomes present that I can move into DSDT and get away from modifying plist files.

 

Explain what/how, if you want to see examples of DSDT exporting data just look at the current DSDT, it has several examples of data injection.