234 replies to this topic

[DoiX]

I'll disassemble it myself and see if can trace the problem related to platforms by comparing it to the old ones. More specifically, HDAPlatform.kext plugin to the new ML AppleHDA. It will be a long shot, but hey. Who doesn't get his fix by staring into lines of numbers?

[toleda]

Great work, must be doing something wrong.  Any ideas?
Testing results with H67N/889/10.8 GM

10.8 AppleHDA_v2.3.0

FF 87 EC 1A 0F 8F 53 01 00 00
FF 87 EC 1A 0F 8F 2F 01 00 00

A. nyolc8 post #25

89 08 EC 10 0F 84 1F 01 00 00
89 08 EC 10 0F 84 FB 00 00 00

B. TimeWalker75a #26

89 08 EC 10 0F 84 8F 02 00 00
89 08 EC 10 0F 84 53 02 00 00

C.  TimeWalker75a #31

89 08 EC 10 0F 84 47 01 00 00
89 08 EC 10 0F 84 23 01 00 00

All failed; no audio devices, same sound assertions:

7/19/12 11:14:59.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1570
7/19/12 11:14:59.000 PM kernel[0] Sound assertion in AppleHDADriver at line 2200
7/19/12 11:14:59.000 PM kernel[0] Sound assertion in AppleHDADriver at line 217
7/19/12 11:14:59.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1055

[TimeWalker75a]

Hey, toleda!
It's a shame this works for some and doesn't do a thing for the others... I myself am struggling to re-enable ALC269 in ML even though I had zero problems with ALC888 patching using the same method (just different value for the respective codec)
You can try this kext http://puu.sh/K6QD
It has been put together for ALC889 by Sergey_Galan over at applelife.ru forums, which incorporates my patch used in post #25.
Even though the node distribution might be a little bit off, you should at least get some of the I\O to show up in system preferences.
If it somewhat works, then your layouts\platforms\pinconfig will need some adjustments to them.

If you're interested how this all goes you can try and read up on applelife. I perfectly understand that google translate is not a best experience and might seem as a waste of time, but at least you can catch the idea. Start at this post: http://applelife.ru/...e-9#post-299106

[TimeWalker75a]

In 10.7 the situation was the following (binary from 10.7.4 analyzed)

000000000003fe11 cmpl $0x11d41983,%ebx
000000000003fe17 jg 0x0003fed1

so to get to the place of AD1984 you were previously zeroing the "AD1983" so the this check would be always positive since any positive number (which our codec id is)  is > 0.

000000000003fed1 cmpl $0x11d41984,%ebx
000000000003fed7 je 0x0003ff08

the address 0x0003ff08  is unique to this codec in 10.7.4, majority of the codecs who's id can't be determined after all the checks are sent to 0x000400f5 if their id doesn't match anything along the way, some are just redirected to another codecs (like ALC261->ALC262 and ALC884 -> ALC885).

000000000003ff08 movl $0x00000530,%edi
000000000003ff0d callq 0x0003ff12
000000000003ff12 testq %rax,%rax
000000000003ff15 movq %rax,%rbx
000000000003ff18 je 0x0004010f ---- this address is common for all the codecs, its the semi-final stage to create the widget I guess

000000000004010f testq %rbx,%rbx
0000000000040112 jne 0x0004012e -- if test has not returned 0 ? then jump to this address else it will cause an assertion in the IOLog


0000000000040114 leaq 0x0001b599(%rip),%rdi
000000000004011b leaq 0x0001cf1f(%rip),%rsi
0000000000040122 movl $0x00000065,%edx
0000000000040127 xorb %al,%al
0000000000040129 callq 0x0004012e -- after the assertion message it would still proceed to the same address.

000000000004012e movq %rbx,%rax
0000000000040131 addq $0x08,%rsp
0000000000040135 popq %rbx
0000000000040136 popq %rbp
0000000000040137 ret - this returns us to where we previously were, so we can proceed to the call operation

000000000003ff1e movq %rbx,%rdi
000000000003ff21 callq __ZN20AppleHDAWidgetAD1984C1Ev

So, the widget element __ZN20AppleHDAWidgetAD1984C1Ev  is called which in the end jumps to __ZN20AppleHDAWidgetAD1984C2Ev which jumps to __ZN20AppleHDAWidgetAD19849MetaClassC1Ev ..
the last one has a ret operator, which enables it to get back to where it left of after the call:

000000000003ff26 jmp 0x0004010f  -- this runs the test again

So, how I mentioned previously some of the codecs get redirected if the id is greater than the one it is compared to

000000000003fe29 cmpl $0x10ec0261,%ebx
000000000003fe2f jg 0x0003ff2b

or

000000000003fe1d cmpl $0x10ec0884,%ebx
000000000003fe23 jg 0x0003ff5a

say .. for ALC262 and ALC855 the situation would be the following.

000000000003ff2b cmpl $0x10ec0262,%ebx
000000000003ff31 jne 0x000400f5   -- if id is not equal (ZF has not been set?) send to an additional test sequence because we failed with ALC261 and now with 262
000000000003ff37 movl $0x00000530,%edi -- else we can initialize the widget much like with the AD1984 described above
000000000003ff3c callq 0x0003ff41
000000000003ff41 testq %rax,%rax
000000000003ff44 movq %rax,%rbx
000000000003ff47 je 0x0004010f
000000000003ff4d movq %rbx,%rdi
000000000003ff50 callq __ZN20AppleHDAWidgetALC262C1Ev
000000000003ff55 jmp 0x0004010f -- so if the call had a ret operator in the end of jumping through widget elements it will go to the common test sequence again ...

000000000003ff5a cmpl $0x10ec0885,%ebx
000000000003ff60 jne 0x000400f5 - same thing here, if we failed with 884 and failed again with 885 then were ought to be tested additionally..
000000000003ff66 movl $0x00000548,%edi - if everything is fine and id has matched then we can initialize the widget
000000000003ff6b callq 0x0003ff70
000000000003ff70 testq %rax,%rax
000000000003ff73 movq %rax,%rbx
000000000003ff76 je 0x0004010f
000000000003ff7c movq %rbx,%rdi
000000000003ff7f callq __ZN20AppleHDAWidgetALC885C1Ev
000000000003ff84 jmp 0x0004010f

now, for the other codecs that are being sent to 0x000400f5 it goes like this:

00000000000400f5 movl $0x00000530,%edi
00000000000400fa callq 0x000400ff
00000000000400ff testq %rax,%rax
0000000000040102 movq %rax,%rbx
0000000000040105 je 0x0004010f

so, as you can see, they go through an additional test sequence in order to get to the common address for the other check 0x0004010f.
so basically I went ahead and on the first check for to match the id i sent it to the location of AD1984 instead of going through all this routine.

__ZN21AppleHDAWidgetFactory20createAppleHDAWidgetEP11DevIdStruct:
000000000003fcd0 pushq %rbp
000000000003fcd1 movq %rsp,%rbp
000000000003fcd4 pushq %rbx
000000000003fcd5 subq $0x08,%rsp
000000000003fcd9 testq %rdi,%rdi
000000000003fcdc jne 0x0003fcfd
000000000003fcde leaq 0x0001b9cf(%rip),%rdi
000000000003fce5 leaq 0x0001d355(%rip),%rsi
000000000003fcec movl $0x00000036,%edx
000000000003fcf1 xorb %al,%al
000000000003fcf3 callq 0x0003fcf8
000000000003fcf8 jmp 0x000400c1
000000000003fcfd movl (%rdi),%ebx
000000000003fcff cmpl $0x10ec0269,%ebx -- here used to be the id of the Wolfson codec (0x1aec87ff)
000000000003fd05 je 0x0003ff08 -- and here used no be a jg operator that would redirect us to the id of 0x1aec8800 in case our id was greater, else it would proceed into deep hole of id matching and would fail eventually.

in 10.8 AD1984 and ALC885 share this  "unique address" which requires them to go through only one test to enable the widget\functiongroup, whereas all of the other codecs if failed to determine the proper id are required to go through both of these tests.

I hope I make sense.

by the way, nyolc8, I hope you don't mind if we turn this thread into a discussion to this problem? Since you have decided to call it so, the title is aplicable to the content that we are discussing .. so you might as well remove the [SOLVED] tag for the title, because as a matter of fact the patching of AppleHDA in ML isn't solved yet.

[toleda]

TimeWalker75a, on 20 July 2012 - 08:12 AM, said:

It's a shame this works for some and doesn't do a thing for the others... I myself am struggling to re-enable ALC269 in ML even though I had zero problems with ALC888 patching using the same method (just different value for the respective codec)
You can try this kext http://puu.sh/K6QD

Thanks for the reply.  I tried the attached AppleHDA.kext with no audio devices result.  Confirmed the AppleHDA binary patch is post #25.  Sound assertions:

7/20/12 1:51:51.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1077
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 1052
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 4544
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 4315
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 4226
7/20/12 1:51:52.000 PM kernel[0] Sound assertion in AppleHDADriver at line 4259

[TimeWalker75a]

Well, the person who has put the kext together said that you are bound to get assertions and that he was getting these in previous ML builds as well, while using the binary patches from RevoGirl's sh script found on her Git repo ...

[bcc9]

TimeWalker75a, on 20 July 2012 - 08:12 AM, said:

Hey, toleda!
It's a shame this works for some and doesn't do a thing for the others... I myself am struggling to re-enable ALC269 in ML even though I had zero problems with ALC888 patching using the same method (just different value for the respective codec)
You can try this kext http://puu.sh/K6QD
It has been put together for ALC889 by Sergey_Galan over at applelife.ru forums, which incorporates my patch used in post #25.

Great, thank you, this one works with my alc889 codec with my gigabyte z68, and 10.8 GM.
Would be nice to put together a general patch script that would take a codec ID as input and patch AppleHDA as appropriate.

[TimeWalker75a]

That again proves that the problem of inconsistency of test results lies in the xmls from 10.7. You see, the problem is .. the offsets and therefore the addresses suffer a slight change for every version of the binary. I know how to calculate the target that we must reach for a decided codec base ie as1984/alc262/alc885. It is not hard, just the binary needs to be disassembled first. I'm not that skilled to write an app, but technically it is possible to make an app that would disasm the binary &  look for a base codec id occurrences in the dumped asm file, thet it would take occurence address, take the address of wolfson codec and calculate the new jump address by using a formula. Then it would replace the id of wolfson with ours and adjust the je operator's bytes to mathc calculated destination address.

[bcc9]

Perhaps something like my ati-personality.pl where the perl code invokes otool and the opcodes & operands of the 64 bit binary are decoded in order to figure out where the patch goes.

[TimeWalker75a]

Im sorry I have never seen this work of yours as Im not an ATI person, but it sounds just about right.

The basic idea is:
1. Find the address of wolfson codec occurrence and the jg opperator address that follows it.
2. Find the decided substitute codec address (say ad1984) and note the destination address that it is being sent to if id mathces
3. Take the above destination address substract the address of jg operator of the wolfson codec and substract 6 bytes which is the lenghts of the argument of jg operator
4. Swap the id of wolfson with your id, swap the jg operator to je (0f 8f to 0f 84) and replace first 2 bytes of the argument with the calculated 2 byte digit.
5. Repeat for another occurrence.

[VCH888]

I tested my ALC662 (945GCM-S2L). patching over 0x1aec87ff of WM8800. see attached files.

 10.8_patching_662.txt   2.69K   115 downloads

add more files
 10.8_patching_662_1.zip   1.15MB   97 downloads

[TimeWalker75a]

Ok, I can confirm the patch has worked for me as well for ALC269... after all the frustration that I went through this past week it appears it was for nothing (I have actually came up with the binary workaround last Saturday). I have taken clean platforms and layouts from a vanilla AppleHDA from 10.8 GM and set my pathmap for internal speakers and adjusted the pinconfig. Now I just need to stop being a lazy bum and adjust my stuff so that it would work for 10.8 ...
This is what I got so far:

[nyolc8]

VCH888, on 21 July 2012 - 04:04 AM, said:

I tested my ALC662 (945GCM-S2L). patching over 0x1aec87ff of WM8800. see attached files.

10.8_patching_662.txt

add more files
10.8_patching_662_1.zip

I used your patch as a perl patch in terminal and my sound assertion errors gone after 1 and half year!!!
So thank you!

[TimeWalker75a]

nyolc8, on 21 July 2012 - 08:55 AM, said:

I used your patch as a perl patch in terminal and my sound assertion errors gone after 1 and half year!!! So thank you!

This is what you get by not using a compatible codec base.
Unfortunately this is not a solution for every codec out there.
With ALC889 you won't be getting any working inputs it you intend to jump to 885 instead of AD1984. Jumping to 885 for ALC269 you won't get any sound what so ever ..

[TimeWalker75a]

Ok, basically what is wrong between 10.7 and 10.8 layouts that break the functionality of the codec is that MuteGPIO and SignalProcessing for some reason confuse the codec on what to do .. I guess something was changed about them in 10.8. If you have these on your INPUT (Mic, LineIn) nodes try removing them, basically leaving the nodes blank. Now speakers, headphones, line-in and internal mic are detected, but it's a miserable experience not having mic boost and noise reduction .. will keep digging and i hope to get assistance on that ..

[TimeWalker75a]

Got this sucker ALC269 to work properly:
http://puu.sh/KrnS
http://puu.sh/KrnZ
http://puu.sh/Krol
http://puu.sh/Krow

Download here: http://puu.sh/Krq6

Used the first damn patch I had calculated exactly a week ago!
I'm just disgusted by some users right now.

[nyolc8]

Your "Line in" transforms into "front mic" if you connect the front mic? How? I got the "back mic" and the "back line in" working, but not the "front mic". (I made the speakers transforming into headphones when I connect a headphone, but I couldn't make the front mic work ever). If you have tips, or instructions, please let me know in PM (I can tell you my pinconfig and nodes and everything).

[TimeWalker75a]

It's a laptop computer, which has just two external jacks. My Line-In is actually a 3.5mm external microphone socket. Everything happens on the opposite of how you though it. By-default it says Internal Microphone, if I plug the jack in it changes to Line-In. Same with Speakers-Headphones.


Also, adding to my latest post regarding MuteGPIO and SignalProcessing for Internal Mic\Line-In pin-default nodes.
I started troubleshooting by disabling the external mic at node 0x18 (used as Line-In in OSX) adjusting it's pinconfig: 01871CF0 01871D00 01871E00 01871F40
I have also removed this node from Platforms and layout (from the Inputs section).
Then I went ahead and looked at the dump of my codec again to find out that it does not support MuteGPIO on node 0x12 (Mic) so it has to be either set as 0, or not set at all. Nor my codec supports DspGainStage processing apaprently. After removing both of these (MuteGPIO and SoundProcessing for Gain) from Mic in may layout pathmap I had a working sound and a working internal mic, with ambient noise suppression.

Then I had reenabled the 0x18 node for Line-In in my pinconfig: 01871C20 01871D30 01871E81 01871F01
Went ahead and poped the 80% MuteGPIO on it since the dump says it's supported. The audio worked fine.
Later I've decided to add SignalProcessing (just the Equalization and NoiseReduction same as with Mic) and revert all of the platforms and layout to enable this jask .. but audio stopped workign after I did that. Then I removed all of the processing from it and it started to work again. So apparently the binary threats this very seriously in 10.8 .. whereas in 10.7 it could be in place and the sound would still work fine.

I went ahead and got a copy of AppleHDA from 10.6.2. to determine ALC262 layout number and check upon that in 10.8 files. Sadly I haven't found any SignalProcessing in 262's layout as of 10.8 meaning that it probably won't work anymore. Oh well, at least I'm happy about the internal Mic's SignalProcessing.

Hope this info helps someone troubleshoot their codec ...

Also, apparently HDMI audio works (HD3000) without touching the SNB framebuffer: http://puu.sh/Kt2h

[VCH888]

nyolc8, on 21 July 2012 - 08:55 AM, said:

I used your patch as a perl patch in terminal and my sound assertion errors gone after 1 and half year!!!
So thank you!

You're welcome.  Actually I should thank to you for posting post #25 and kext @ ....x86.net because I learnt from what you did.

You can get your rear pink and blue ports to be output for you ALC662.
see ALC662HDA_Lion_MLion_V1.00.zip layout-id = 48, credit to toleda for finding pink output.
note: got to see codec dump from linux which port supports both input and output.

**************
This is how I did on ALC889 of Z68XP-UD3R.
 post_to_insanelymac_alc889.txt   3.81K   63 downloads

[nyolc8]

Thanks, but I'm using my rear mic, there is a mic always pluggied in, and it's recognized as builtin mic. I just want to make the front mic work. I'll try to merge somehow the layout 12 and 48 (if it's possible).

edit.: okay, I tried many ways, but sound completely dissapears when I made any modifications for the front mic node setting in platforms.xml.zlib... I tried to modify layout12.xml.zlib with layout48.xml.zlib elements but nothing... It's only possible to have one mic port and one line in? I tried to make IntMic, and ExtMic but no change, the mic nodes are in the same group in platforms.xml.zlib for autoswitch but it just not working.

I'm just not that pro to figure out this