Jump to content

[Need help] Can't get audio: IDT 92HD91BXX to work on Sierra


8 posts in this topic

Recommended Posts

[sOLVED!] AUDIO WORKS NOW! (Platforms12.xml, Replaced node 15 with node 13 and that's it! :D)

So just to clarify this is all I have for working audio in sierra:

1. Standard DSDT HDEF edit with layout-id 12 / 0x0c

2. AppleALC.kext with slightly modified Platforms12.xml of IDT92HD91BXX folder: node 15 changed to node 13 as mentioned above

 

(That's it, no clover patches, or anything else)

 

 

Ok lets get right into it, I have close to everything I want working except Audio, HDMI out, HDMI Audio out, Native touchpad (for two fingered scrolling), Battery Indicator, and probably not going to happen (Nvidia optimus acceleration, but that's fine I'll just use the intel integrated for OS X)


Lets focus on the Audio for now, and I'll get help or figure out the other last remaining things later! :)

On 10.11 I learned a lot, patched my DSDT (made things much smoother + got wifi and audio working without anything else needed) , generated pikeralpha SSDT for proper cpu stepping, modified SSDT for Rehabman's USBInjectAll port injector (which enabled built in Bluetooth + built in webcam, and isolated just my ports properly)


So just the other day I figured Sierra's been out of beta for a while and it was time to upgrade 10.11->10.12, created a new EFI and hfs+ and ext4 (for linux :)) partition on a fresh hard disk and installed 10.12.2 from a secondary small hfs+ partition that I had installed the OS X installer to which inherited my awesomely configured Clover bootloader data (config.plist, DSDT/SSDTs, etc) and the freshest extra drivers I need (namely VoodooPS2, and USBInjectAll, and of course FakeSMC) in CLOVER/kexts/10.12


Everything went smoothly, which resulted in a totally vanilla Sierra! (with the exception of the BTFirmwareUploader.kext for bluetooth to work [combined with proper usb port injection])


But before I could get comfortable with my new install, I noticed the audio was no longer working like it does on my 10.11 install that I still have...


Remembering back to how I got it working in 10.11 I tried many options: directly patching AppleHDA manually, using a HDAenabler for my particular device (or so I thought), and it was the simple DSDT HDEF patch with layout ID 0x0C / 12 which I what I believe actually did it and that alone (without even any Clover on the fly patches of AppleHDA)...


Here's what my HDEF DSDT entry looks like currently: (It's real simple it just sets the layout-id to 12, basically which is the layout that worked for me then not sure why exactly but I guess that's why I'm reaching out, to understand this better so I can fix it myself in the future...)

Device (HDEF)
        {
            Name (_ADR, 0x001B0000)
            OperationRegion (HDAR, PCI_Config, 0x4C, 0x10)
            Field (HDAR, WordAcc, NoLock, Preserve)
            {
                DCKA,   1,
                        Offset (0x01),
                DCKM,   1,
                    ,   6,
                DCKS,   1,
                        Offset (0x08),
                    ,   15,
                PMES,   1
            }

            Method (_DSM, 4, NotSerialized)
            {
                If (LEqual (Arg2, Zero))
                {
                    Return (Buffer (One)
                    {
                        0x03
                    })
                }

                Store (Package (0x06)
                    {
                        "layout-id",
                        Buffer (0x04)
                        {
                            0x0C, 0x00, 0x00, 0x00
                        },

                        "hda-gfx",
                        Buffer (0x0A)
                        {
                            "onboard-1"
                        },

                        "PinConfigurations",
                        Buffer (Zero) {}
                    }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
            }
        }



I'm not sure what the DTGP method is for, but guides on here were saying to add it so I did to see if it would help on sierra... Previously working on it in 10.11 I had it just merely immediately returning the package created containing the layout-id in the _DSM method... Now it appears to store it in Local0 first, pass a reference to that along with args0-3 to the DTGP method and then finally the result of what that may have done to the package (now pointed to by Local0) is returned by the _DSM method...


There's something I don't understand about this patch though... Why is the PinConfigurations buffer always empty / Zero bytes in everyone's (that I've seen) DSDT edit? Can the PinConfigurations not be set here? If not then why include it at all?


I'm asking this because through my troubleshooting I've suspected that is where my problem lies, with an improper pin configuration (which is for some reason correct by default on 10.11, but not on 10.12)


When I try to mod the PinConfigurations buffer with the working pin configuration I have grabbed from IOReg on my 10.11 OS it just doesn't take effect like layout-id and hda-gfx do or any other properties I've experimented adding to it.


Something is overriding the PinConfigurations you might think you can set here in the DSDT isn't it?


 

The closest I've gotten is actually very close to working audio... With this DSDT layout patch and AppleALC.kext in CLOVER/kexts/other by vit and nothing else for audio besides that the audio device appears and I can 'set' the volume with fn keys or the usual way adjusting the volume sliders but it doesn't actually output any sound... Neither does the internal mic work.

 

However then on top of that when I add these clover patches that I found on here that are supposed to patch AppleHDA for my codec the internal microphone (haven't actually tested it but the levels show indicating it's picking up sound) works but still not the audio! what gives!!

<dict>
                <key>Comment</key>
                <string>AppleHDA IDT 76e0 (1 of 4)</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>
                PYsZ1BE=
                </data>
                <key>Name</key>
                <string>AppleHDA</string>
                <key>Replace</key>
                <data>
                PeB2HRE=
                </data>
            </dict>
            <dict>
                <key>Comment</key>
                <string>AppleHDA IDT 76e0 (2 of 4)</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>
                PYQZ1BE=
                </data>
                <key>Name</key>
                <string>AppleHDA</string>
                <key>Replace</key>
                <data>
                PQAAAAA=
                </data>
            </dict>
            <dict>
                <key>Comment</key>
                <string>AppleHDA IDT 76e0 (3 of 4)</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>
                PYMZ1BE=
                </data>
                <key>Name</key>
                <string>AppleHDA</string>
                <key>Replace</key>
                <data>
                PQAAAAA=
                </data>
            </dict>
            <dict>
                <key>Comment</key>
                <string>AppleHDA IDT 76e0 (4 of 4)</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>
                PYoZ1BE=
                </data>
                <key>Name</key>
                <string>AppleHDA</string>
                <key>Replace</key>
                <data>
                PQAAAAA=
                </data>
            </dict>

Those are the newest patches I found and when I compared them to what I was already playing around with that I got from AppleHDA Patcher, I realized they are the same except the addition of one extra zeroing of 4 bytes with the same codec patch: (all the above did besides the extra one is add an extra byte to each 'Find' data field I guess to help find it better, eliminate any false positives...

<dict>
                <key>Comment</key>
                <string>Patching 11d4198b with 111d76e0 codec (patched by AppleHDA Patcher.app)</string>
                <key>Disabled</key>
                <true/>
                <key>Find</key>
                <data>
                ixnUEQ==
                </data>
                <key>Name</key>
                <string>AppleHDA</string>
                <key>Replace</key>
                <data>
                4HYdEQ==
                </data>
            </dict>
            <dict>
                <key>Comment</key>
                <string>Zeroing 11d41984 codec (patched by AppleHDA Patcher.app)</string>
                <key>Disabled</key>
                <true/>
                <key>Find</key>
                <data>
                hBnUEQ==
                </data>
                <key>Name</key>
                <string>AppleHDA</string>
                <key>Replace</key>
                <data>
                AAAAAA==
                </data>
            </dict>
            <dict>
                <key>Comment</key>
                <string>Zeroing 11d4198a codec (patched by AppleHDA Patcher.app)</string>
                <key>Disabled</key>
                <true/>
                <key>Find</key>
                <data>
                ihnUEQ==
                </data>
                <key>Name</key>
                <string>AppleHDA</string>
                <key>Replace</key>
                <data>
                AAAAAA==
                </data>
            </dict>

One thing real quick though, how can you easily convert between that (base64? It doesn't seem like it) and hex? I've been using insert that into config.plist and clover configurator shows the hex when you open the config with it, or vice versa add a disabled patch with some hex and save and the config shows the wierd base64 format in the config.plist opened in a text editor/ or plist editor... A bit convoluted but even the built in converted in CC doesn't work, it says it's not valid base64! wtf is it then! Even base64 converters kind of work but there's junk mixed in with it (it feels like anyway) So how is everyone converted that to hex and vice versa so easily? Where did I miss that memo? lol!

Now back to fixing the audio... Remembering from back from fixing my USB ports I remembered that IOReg helped out a lot in seeing what the difference was between a working component and a non working one, so I saved the IOReg from 10.11 with working audio, and compared it to my 10.12 with non working audio... And the first thing that seems important that is different under the HDEF Registry is the PinConfigurations and then after that the working 10.11 reg shows more stuff underneath that! Like when the USB ports are working devices show up under them, whereas they don't when it isn't working or unavailable.


See here: (and the IORegs are attached below also)IOReg_Screenshot_HDEF.png

See how under the AppleHDA Driver, there's the AppleHDAEngineInput and AppleHDAStream, etc all that and the rest is missing from my 10.12 IOReg information!

 

When I do the above though to where I get the audio looking like its going to work, or audio looks like it works and mic is actually working, it does fill out quite like the working comparison in 10.11 despite the sound output not actually coming out.

 

So that's what leads me to believe my PinConfigurations might be the culprit! Maybe its detecting the audio device now sure, but its trying to output the audio on the wrong pins therefore its not actually coming out! Maybe the mic working with the addition of either of those sets of Clover patches can still be explained in that the mic pins happen to still be correct (some bytes of the PinConfigurations do match up) and/or the AppleALC isnt doing the right patches for me / my device and therefore one of those extra patches activates the sound output and the microphone, just with the problem of the sound output not having the right pin configuration set!

 

So I either need a proper pin configuration or a different patch / set of patches is I think what I've narrowed the problem down to!? 

 

[CORRECTED]

Looking inside AppleALC.kext I think I found where to modify the PinConfigurations for my device:

AppleALC.kext->Contents->PlugIns->PinConfigs.kext->Contents->Info.plist

92HD91BXX only yields 2 matches in the entire plist file:


<dict>

                    <key>AFGLowPowerState</key>

                    <data>AwAAAA==</data>

                    <key>Codec</key>

                    <string>Mirone - IDT 92HD91BXX </string>

                    <key>CodecID</key>

                    <integer>287143648</integer>

                    <key>ConfigData</key>

                    <data>AKccAACnHRAApx6BAKcfAQC3HBAAtx0QALceIQC3HwMAxxwgAMcdAADHHgAAxx9JARccMAEXHQABFx6gARcfmQDXHEAA1x0BANceFwDXH5kA5xxQAOcdEADnHgEA5x8jAQccYAEHHQABBx4AAQcfSQH3HHAB9x0AAfceAAH3H0kCBxyAAgcdAAIHHgACBx9J</data>

                    <key>FuncGroup</key>

                    <integer>1</integer>

                    <key>LayoutID</key>

                    <integer>3</integer>

                </dict>

                <dict>

                    <key>AFGLowPowerState</key>

                    <data>AwAAAA==</data>

                    <key>Codec</key>

                    <string>RehabMan - IDT 92HD91BXX for HP Envy</string>

                    <key>CodecID</key>

                    <integer>287143648</integer>

                    <key>ConfigData</key>

                    <data>AKccAACnHRAApx6BAKcfAQC3HBAAtx0QALceIQC3HwMAxxwgAMcdAADHHgAAxx9JARccMAEXHQABFx6gARcfmQD3HEAA9x0BAPceFwD3H5kA5xxQAOcdEADnHgEA5x8jAQccYAEHHQABBx4AAQcfSQH3HHAB9x0AAfceAAH3H0kCBxyAAgcdAAIHHgACBx9J</data>

                    <key>FuncGroup</key>

                    <integer>1</integer>

                    <key>LayoutID</key>

                    <integer>12</integer>

                </dict>

The first one might explain why none of AppleHDA Patchers options worked for me, since layout 3 doesn't ever come up with any audio device at all for me (yes I was even willing to go non-vanilla for a bit if the AppleHDA patched kext would work but even that was a no go) Also the AFGLowPowerState not sure if that has anything to do with it as well, what is that?

 

So the problem is to replace the ConfigData with the data from 10.11 PinConfigurations data where the sound actually works! But as noted above if this is not base64 then what is it?

 

I think if I convert this: 20 10 81 01 50 10 21 01 30 01 10 90 10 01 a0 90 e0 00 56 28 (hex) into a lettered string like Rehabman has there for his HP Envy, and replace that string with mine it just might work!! What do think?

 

So far I did the clover configurator makeshift method of converting that hp envy string and got this:
00A71C0000A71D1000A71E8100A71F0100B71C1000B71D1000B71E2100B71F0300C71C2000C71D0000C71E0000C71F4901171C3001171D0001171EA001171F9900F71C4000F71D0100F71E1700F71F9900E71C5000E71D1000E71E0100E71F2301071C6001071D0001071E0001071F4901F71C7001F71D0001F71E0001F71F4902071C8002071D0002071E0002071F49

 

But it doesn't appear to match up with my 10.12 (nonworking) PinConfigurations as reported by IOReg:
20 10 a1 04 1f 10 21 04 10 01 17 90 f1 00 00 40 f2 00 00 40 f3 00 00 40 30 01 a3 d5 f4 00 00 40 f5 00 00 40 e0 00 56 28 e0 00 56 28

 

So I don't know if I'm converting it wrong or what... but I need some expert audio advice on what to do next because I'm kind of stuck here!

 

Thanks for your help fellow osx86_64'r :D

I can post more info if neccesary DSDT, SSDTs, etc... But I think the codec dump from linux and the two different ioregs and the information I provided should help to figure out where Sierra has gone wrong with my audio device!

 

Now I'm off to go eat something good and then I should be able to think about this more clearly or if someone responds at that point and figures this out before me :)!

Thanks again,

WhistlingMoonTraveller

codec_dump.txt

Working and Non Working Audio IORegs.zip

Link to comment
Share on other sites

try with applealc

attachicon.gifAppleALC.kext.zip

 

u can use id 3 or 12

attachicon.gifDaNiEl 2017-02-18 às 23.58.11.png

 

applehda stay original

 

https://github.com/vit9696/AppleALC

Thanks for the response MaLd0n, however see I must be tired and worn out trying to fix this, as I have to correct my post, I meant to say AppleALC where I wrote AppleHDA sorry about that... As I've already gotten the furthest i've gotten so far with AppleALC by vit!!!

 

 

This: Looking inside AppleHDA.kext I think I found where to modify the PinConfigurations for my device:

 

AppleHDA.kext->Contents->PlugIns->PinConfigs.kext->Contents->Info.plist

 

is really this:

 

Looking inside AppleALC.kext I think I found where to modify the PinConfigurations for my device:

 

AppleALC.kext->Contents->PlugIns->PinConfigs.kext->Contents->Info.plist

 

 

Essentially I believe I need a modified AppleALC with my pin configuration that is correct for me & my device & device revision! And maybe something new with sierra where things that worked before because things just happened to be correct are no longer correct in sierra and need to be corrected/patched properly!

 

Yes my AppleHDA is original in /S/L/E and the latest AppleALC is in my Clover/kexts/other (so it's version independent and I can keep vanilla). And yes I realize AppleHDA isnt patched on disk, but it is still patched while its loaded on the fly by AppleALC isn't it? :)

 

Can the PinConfigs.kext inside AppleALC be modded? Or does it have to be recompiled?

 

Layout 3 in DSDT HDEF edit yields no audio device, same as if not using AppleALC at all... Layout 12 is very close but no dice... It shows up lets me change the volume up or down but no sound actually comes out! microphone works but not audio if I combine that with those clover patches I posted... Without AppleALC those patches to nothing same as layout ID, where as in 10.11 the layout ID 12 did everything! and that is all that was needed... By the way it shouldn't require any extra clover patches right? as those could interfere with it? The combination of those and AppleALC getting even the microphone to work though tells me AppleALC isn't doing everything needed for me, so I need to mod it!

 

 

As shown above in the image this is the pin configuration that works on 10.11: 20 10 81 01 50 10 21 01 30 01 10 90 10 01 a0 90 e0 00 56 28

 

This is the one I get for some reason on 10.12: 20 10 a1 04 1f 10 21 04 10 01 17 90 f1 00 00 40 f2 00 00 40 f3 00 00 40 30 01 a3 d5 f4 00 00 40 f5 00 00 40 e0 00 56 28 e0 00 56 28

 

Not only does it not match up but it's longer too:

20 10 81 01 50 10 21 01 30 01 10 90 10 01 a0 90 e0 00 56 28 //Good

20 10 a1 04 1f 10 21 04 10 01 17 90 f1 00 00 40 f2 00 00 40 f3 00 00 40 30 01 a3 d5 f4 00 00 40 f5 00 00 40 e0 00 56 28 e0 00 56 28 //Bad

 

I'm not sure what bytes have to be changed to the sound to come out but Having the volume control and audio detected and mic working is promising...

 

For example if the third byte can be changed from a1 to 81 that even might be the solution right there, if that happens to be the byte that decides what pins the audio is output on, it could be any one of those twenty bytes that are different which happens to be 13 different bytes... Does one of those 13 bytes hold the answer? Well that's what I'm asking!

 

A user where Mic works audio out does not: (like me)

http://www.insanelymac.com/forum/topic/293863-applehda-patch-requests/?p=2357204

 

A user that claims to have solved it with the same device as me (but isn't very clear what his solution was):

http://www.insanelymac.com/forum/topic/311293-applealc-—-dynamic-applehda-patching/?p=2331107

 

AppleALC isn’t playing well for this user and this device:

http://www.insanelymac.com/forum/topic/312278-shiki-—-userspace-patcher/?p=2355746

 

Finally what is a good way to get my ENTIRE boot log in 10.12? Things seem to have changed where the logs are all split up and I can't find anything early boot... And immediately after logging in doing a sudo dmesg gets cut off and doesn't go back far enough, and bdmesg only is clover related stuff and stops after that! I only ask this as I have seen AppleALC 0 out of 2patches applied (or similarly worded) flash by real quick sometimes I catch it... Then I have no way to look back and see if it patched anything successfully! Does it even output anything if it does patch something or only if it doesn't?

 

Well I'm confident this can work as I have it working right now on 10.11 wtf! lol :D Thanks again!

Link to comment
Share on other sites

Great news fellow community members!! I've finally solved it!!! :thumbsup_anim:

 

Just a glimpse into what my world has been like for a little while!

 

As you can see I got hung up on PinConfiguration for a while and I nearly learned the ins and outs of that aspect of all this without that actually being my solution...

7ltW5sP.png

It wasn't until I got so amped up trying pin configurations that I just made everything a speaker! (see next image below) lol and still no output then I started getting the feeling it was something else and not pin configuration! Especially since I could have a proper / somewhat proper pin config and actually get the speakers to come up in the proper place (audio ouput) and sound would work out of the headphones and input from the mic with a proper enough pin config... There had to be something more I was missing!

 

Played around with CodecCommander even, but it seemed my EAPD values were correct though (0x2 is on I'm fairly certain) and still no sound so that didn't appear to be it either

 

So if it's not the pin config, and its not the EAPD amp not turning on, then what is it?!

PmVXBQG.png

 

Further down into Mirone's AppleHDA patching guide I finally got past the pinconfigurations and onto the PathMaps! :) After getting a visualization from the codec grapher, that brought it into a much nicer perspective and I saw that I needed at 13 -> 20 path map for my speaker to work! Low and behold the Platforms12.xml included in the IDT92HD91BXX folder of the AppleALC did not have a mapping leading down that path! The other paths are fine though (as everything else worked)! So I change the path map starting with NodeID 15 into NodeID 13!! Recompress the xml into zlib copy it into folder noted above in AppleALC source code, Rebuilt, thrown in clover kexts folder replacing original!

 

AND IT WORKS! :)

 

rV17lg9.png

 

Well I was right about one thing, it did still come down to only 1 byte being the problem! :) Except it just wasn't the first byte that came to mind, nor even a byte in that set! :hysterical:

 

Special thanks to Mirone for his helpful guide at troubleshooting my way to figuring out what was my problem! :yes:

And to MaLd0n for taking an interest and replying to my post!

 

The next last few things are going to be harder, but now I've got this sorted and because of it I'll likely be able to handle better when encountering audio issues in the future!

  • Like 2
Link to comment
Share on other sites

Great news fellow community members!! I've finally solved it!!! :thumbsup_anim:

 

Just a glimpse into what my world has been like for a little while!

 

As you can see I got hung up on PinConfiguration for a while and I nearly learned the ins and outs of that aspect of all this without that actually being my solution...

7ltW5sP.png

It wasn't until I got so amped up trying pin configurations that I just made everything a speaker! (see next image below) lol and still no output then I started getting the feeling it was something else and not pin configuration! Especially since I could have a proper / somewhat proper pin config and actually get the speakers to come up in the proper place (audio ouput) and sound would work out of the headphones and input from the mic with a proper enough pin config... There had to be something more I was missing!

 

Played around with CodecCommander even, but it seemed my EAPD values were correct though (0x2 is on I'm fairly certain) and still no sound so that didn't appear to be it either

 

So if it's not the pin config, and its not the EAPD amp not turning on, then what is it?!

PmVXBQG.png

 

Further down into Mirone's AppleHDA patching guide I finally got past the pinconfigurations and onto the PathMaps! :) After getting a visualization from the codec grapher, that brought it into a much nicer perspective and I saw that I needed at 13 -> 20 path map for my speaker to work! Low and behold the Platforms12.xml included in the IDT92HD91BXX folder of the AppleALC did not have a mapping leading down that path! The other paths are fine though (as everything else worked)! So I change the path map starting with NodeID 15 into NodeID 13!! Recompress the xml into zlib copy it into folder noted above in AppleALC source code, Rebuilt, thrown in clover kexts folder replacing original!

 

AND IT WORKS! :)

 

rV17lg9.png

 

Well I was right about one thing, it did still come down to only 1 byte being the problem! :) Except it just wasn't the first byte that came to mind, nor even a byte in that set! :hysterical:

 

Special thanks to Mirone for his helpful guide at troubleshooting my way to figuring out what was my problem! :yes:

And to MaLd0n for taking an interest and replying to my post!

 

The next last few things are going to be harder, but now I've got this sorted and because of it I'll likely be able to handle better when encountering audio issues in the future!

I have the same codec, can you provide me the layout12.xml, Platforms.xml and the Pin config you used? Also I tried AppleALC and could never get it to work for this codec on my Envy j-000 but injector kext works just fine.

Link to comment
Share on other sites

I have the same codec, can you provide me the layout12.xml, Platforms.xml and the Pin config you used? Also I tried AppleALC and could never get it to work for this codec on my Envy j-000 but injector kext works just fine.

 

Sure Andrw, maybe my slight alteration will work for you too, but even if not I'll help you debug / figure out why its not working with AppleALC... You could even check out your injector kext you have been able to get to work and see what's in it that makes it work! A slight heads up though, I spent too much time with pin config and learned that pin config is not as important as the PathMaps in PlatformsXX.xml

 

You can have the most beautiful nearly perfect pin configuration, and still no audio output / input (since it doesn't know the right path to actually reach your internal speaker / whatever isnt working).

 

First off does your speakers look like they work, but just no sound comes out when you try the standard released/updated by vit AppleALC? That's what I experienced, I eventually figured out that that meant I had a proper pin configuration and proper audio injection, but just no valid pathmap to actually output the sound. Everything else worked, internal mic, external mic (as line in), and headphones (properly detected when inserted / removed)

 

So do you experience other working devices working / or present in the audio options window? or is it just no audio devices listed at all (output nor input)? We have two built in options layout 12 and layout 3 have you tried both of them (I'm guessing yes) and which way do you inject your layout id, clover or dsdt?

 

I've attached the AppleALC I recompiled containing my fix, and also the Platforms12.xml->Platforms12.xml.zlib which was my edit, and also a quickly made 'zlib-raw.py' python script (in case you don't have a way of doing that yet and you do end up needing to fix it yourself slightly as well)

#!/usr/bin/env python



#raw zlib Compress/Decompress

# Examples: (Don't forget: "chmod +x zlib-raw.py" first)

#  ./zlib-raw.py -d Platforms12.xml.zlib -> Platforms12.xml

#  ./zlib-raw.py -c Platforms12.xml -> Platforms12.xml.zlib

#OR python zlib-raw.py -c layout12.xml -> layout12.xml.zlib



import sys

import zlib



i = 0

for arg in sys.argv:

    i += 1

    if arg == "-d":

        print "Decompressing raw zlib: "+sys.argv[i]+" ..."

        with open(sys.argv[i].replace(".zlib",""),"w") as decompressedfile:

            decompressedfile.write(zlib.decompress(open(sys.argv[i]).read()))

        break

    if arg == "-c":

        print "Compressing raw zlib: "+sys.argv[i]+" ..."

        with open(sys.argv[i]+".zlib","w") as compressedfile:

            compressedfile.write(zlib.compress(open(sys.argv[i]).read()))

        break



print "Done!"

Also a way to go from hex string to binary then to base64 encoded string, and vice versa in case you really do need to adjust the pin config as well:

[And this is the pin config I'm using (the default one as I hadn't changed it in the recompiled AppleALC kext, so I'm using the "RehabMan - IDT 92HD91BXX for HP Envy" for layout 12 and our codec 111d:76e0)]

The pin configs I was creating from my codec_dump.txt were very similar anyways so this one is good enough (as I said earlier the pinconfig is less important than the PathMaps)

echo -e "\nConfigData:"; echo "00a71c00 00a71d10 00a71e81 00a71f01 00b71c10 00b71d10 00b71e21 00b71f03 00c71c20 00c71d00 00c71e00 00c71f49 01171c30 01171d00 01171ea0 01171f99 00f71c40 00f71d01 00f71e17 00f71f99 00e71c50 00e71d10 00e71e01 00e71f23 01071c60 01071d00 01071e00 01071f49 01f71c70 01f71d00 01f71e00 01f71f49 02071c80 02071d00 02071e00 02071f49" | xxd -r -p - | base64 -



ConfigData:

AKccAACnHRAApx6BAKcfAQC3HBAAtx0QALceIQC3HwMAxxwgAMcdAADHHgAAxx9JARccMAEXHQABFx6gARcfmQD3HEAA9x0BAPceFwD3H5kA5xxQAOcdEADnHgEA5x8jAQccYAEHHQABBx4AAQcfSQH3HHAB9x0AAfceAAH3H0kCBxyAAgcdAAIHHgACBx9J
 
echo "AKccAACnHRAApx6BAKcfAQC3HBAAtx0QALceIQC3HwMAxxwgAMcdAADHHgAAxx9JARccMAEXHQABFx6gARcfmQD3HEAA9x0BAPceFwD3H5kA5xxQAOcdEADnHgEA5x8jAQccYAEHHQABBx4AAQcfSQH3HHAB9x0AAfceAAH3H0kCBxyAAgcdAAIHHgACBx9J" | base64 -D - | hexdump

0000000 00 a7 1c 00 00 a7 1d 10 00 a7 1e 81 00 a7 1f 01

0000010 00 b7 1c 10 00 b7 1d 10 00 b7 1e 21 00 b7 1f 03

0000020 00 c7 1c 20 00 c7 1d 00 00 c7 1e 00 00 c7 1f 49

0000030 01 17 1c 30 01 17 1d 00 01 17 1e a0 01 17 1f 99

0000040 00 f7 1c 40 00 f7 1d 01 00 f7 1e 17 00 f7 1f 99

0000050 00 e7 1c 50 00 e7 1d 10 00 e7 1e 01 00 e7 1f 23

0000060 01 07 1c 60 01 07 1d 00 01 07 1e 00 01 07 1f 49

0000070 01 f7 1c 70 01 f7 1d 00 01 f7 1e 00 01 f7 1f 49

0000080 02 07 1c 80 02 07 1d 00 02 07 1e 00 02 07 1f 49

0000090

 

You still might need your codec_dump.txt made from a linux distro though, not for pin config, but instead for validating your PathMaps! I really think Mirone's guide should've had the PlatformsXX.xml+layoutXX.xml part before the pin configuration part as it is more important...

 

The pathmaps are contained in the PlatformsXX.xml file and start like this:

<key>PathMaps</key>

    <array>

        <dict>

            <key>PathMap</key>

            <array>

                <array>

                    <array>

                        <array>

                            <dict>

                                <key>NodeID</key>

                                <integer>21</integer>

                                <key>ProcessingState</key>

                                <true/>

                            </dict>

                            <dict>

                                <key>Amp</key>

                                <dict>

This is the relevant part of the PathMap for me:

<dict>

                                <key>NodeID</key>

                                <integer>13</integer>

                            </dict>

                            <dict>

                                <key>Amp</key>

                                <dict>

                                    <key>Channels</key>

                                    <array>

                                        <dict>

                                            <key>Bind</key>

                                            <integer>1</integer>

                                            <key>Channel</key>

                                            <integer>1</integer>

                                        </dict>

                                        <dict>

                                            <key>Bind</key>

                                            <integer>2</integer>

                                            <key>Channel</key>

                                            <integer>2</integer>

                                        </dict>

                                    </array>

                                    <key>MuteInputAmp</key>

                                    <false/>

                                    <key>PublishMute</key>

                                    <true/>

                                    <key>PublishVolume</key>

                                    <true/>

                                    <key>VolumeInputAmp</key>

                                    <false/>

                                </dict>

                                <key>NodeID</key>

                                <integer>28</integer>

                            </dict>

                            <dict>

                                <key>NodeID</key>

                                <integer>27</integer>

                            </dict>

                            <dict>

                                <key>NodeID</key>

                                <integer>20</integer>

                            </dict>

See how Node 20 is at the bottom, and Node 13 at the top? In my edited Platforms12.xml I now have a path from Node 13 that can reach Node 20 and therefore I now have sound! (As shown in my first screenshot of OP, my internal speaker needs that path)

 

As a last resort if you can't seem to isolate which node you need to change/add, you can just copy the Platforms.xml + layout.xml that works for you in your injector you have and overwrite the layout[iD].xml.zlib and Platform[iD].xml.zlib with compressed versions of them in the AppleALC source yourself and recompile and that should work :)

 

I do highly recommend doing the codec graph part of the Mirone AppleHDA patching tutorial, as then you'll know what you need rather than just having to make sure you keep a copy of your known working layout+Platforms xmls! :D

AppleALC-fixedforme-and-my-Platforms12.xml.zip

Link to comment
Share on other sites

Sure Andrw, maybe my slight alteration will work for you too, but even if not I'll help you debug / figure out why its not working with AppleALC... You could even check out your injector kext you have been able to get to work and see what's in it that makes it work! A slight heads up though, I spent too much time with pin config and learned that pin config is not as important as the PathMaps in PlatformsXX.xml

 

You can have the most beautiful nearly perfect pin configuration, and still no audio output / input (since it doesn't know the right path to actually reach your internal speaker / whatever isnt working).

 

First off does your speakers look like they work, but just no sound comes out when you try the standard released/updated by vit AppleALC? That's what I experienced, I eventually figured out that that meant I had a proper pin configuration and proper audio injection, but just no valid pathmap to actually output the sound. Everything else worked, internal mic, external mic (as line in), and headphones (properly detected when inserted / removed)

 

So do you experience other working devices working / or present in the audio options window? or is it just no audio devices listed at all (output nor input)? We have two built in options layout 12 and layout 3 have you tried both of them (I'm guessing yes) and which way do you inject your layout id, clover or dsdt?

 

I've attached the AppleALC I recompiled containing my fix, and also the Platforms12.xml->Platforms12.xml.zlib which was my edit, and also a quickly made 'zlib-raw.py' python script (in case you don't have a way of doing that yet and you do end up needing to fix it yourself slightly as well)

#!/usr/bin/env python



#raw zlib Compress/Decompress

# Examples: (Don't forget: "chmod +x zlib-raw.py" first)

#  ./zlib-raw.py -d Platforms12.xml.zlib -> Platforms12.xml

#  ./zlib-raw.py -c Platforms12.xml -> Platforms12.xml.zlib

#OR python zlib-raw.py -c layout12.xml -> layout12.xml.zlib



import sys

import zlib



i = 0

for arg in sys.argv:

    i += 1

    if arg == "-d":

        print "Decompressing raw zlib: "+sys.argv[i]+" ..."

        with open(sys.argv[i].replace(".zlib",""),"w") as decompressedfile:

            decompressedfile.write(zlib.decompress(open(sys.argv[i]).read()))

        break

    if arg == "-c":

        print "Compressing raw zlib: "+sys.argv[i]+" ..."

        with open(sys.argv[i]+".zlib","w") as compressedfile:

            compressedfile.write(zlib.compress(open(sys.argv[i]).read()))

        break



print "Done!"

Also a way to go from hex string to binary then to base64 encoded string, and vice versa in case you really do need to adjust the pin config as well:

[And this is the pin config I'm using (the default one as I hadn't changed it in the recompiled AppleALC kext, so I'm using the "RehabMan - IDT 92HD91BXX for HP Envy" for layout 12 and our codec 111d:76e0)]

The pin configs I was creating from my codec_dump.txt were very similar anyways so this one is good enough (as I said earlier the pinconfig is less important than the PathMaps)

echo -e "\nConfigData:"; echo "00a71c00 00a71d10 00a71e81 00a71f01 00b71c10 00b71d10 00b71e21 00b71f03 00c71c20 00c71d00 00c71e00 00c71f49 01171c30 01171d00 01171ea0 01171f99 00f71c40 00f71d01 00f71e17 00f71f99 00e71c50 00e71d10 00e71e01 00e71f23 01071c60 01071d00 01071e00 01071f49 01f71c70 01f71d00 01f71e00 01f71f49 02071c80 02071d00 02071e00 02071f49" | xxd -r -p - | base64 -



ConfigData:

AKccAACnHRAApx6BAKcfAQC3HBAAtx0QALceIQC3HwMAxxwgAMcdAADHHgAAxx9JARccMAEXHQABFx6gARcfmQD3HEAA9x0BAPceFwD3H5kA5xxQAOcdEADnHgEA5x8jAQccYAEHHQABBx4AAQcfSQH3HHAB9x0AAfceAAH3H0kCBxyAAgcdAAIHHgACBx9J
 
echo "AKccAACnHRAApx6BAKcfAQC3HBAAtx0QALceIQC3HwMAxxwgAMcdAADHHgAAxx9JARccMAEXHQABFx6gARcfmQD3HEAA9x0BAPceFwD3H5kA5xxQAOcdEADnHgEA5x8jAQccYAEHHQABBx4AAQcfSQH3HHAB9x0AAfceAAH3H0kCBxyAAgcdAAIHHgACBx9J" | base64 -D - | hexdump

0000000 00 a7 1c 00 00 a7 1d 10 00 a7 1e 81 00 a7 1f 01

0000010 00 b7 1c 10 00 b7 1d 10 00 b7 1e 21 00 b7 1f 03

0000020 00 c7 1c 20 00 c7 1d 00 00 c7 1e 00 00 c7 1f 49

0000030 01 17 1c 30 01 17 1d 00 01 17 1e a0 01 17 1f 99

0000040 00 f7 1c 40 00 f7 1d 01 00 f7 1e 17 00 f7 1f 99

0000050 00 e7 1c 50 00 e7 1d 10 00 e7 1e 01 00 e7 1f 23

0000060 01 07 1c 60 01 07 1d 00 01 07 1e 00 01 07 1f 49

0000070 01 f7 1c 70 01 f7 1d 00 01 f7 1e 00 01 f7 1f 49

0000080 02 07 1c 80 02 07 1d 00 02 07 1e 00 02 07 1f 49

0000090

 

You still might need your codec_dump.txt made from a linux distro though, not for pin config, but instead for validating your PathMaps! I really think Mirone's guide should've had the PlatformsXX.xml+layoutXX.xml part before the pin configuration part as it is more important...

 

The pathmaps are contained in the PlatformsXX.xml file and start like this:

<key>PathMaps</key>

    <array>

        <dict>

            <key>PathMap</key>

            <array>

                <array>

                    <array>

                        <array>

                            <dict>

                                <key>NodeID</key>

                                <integer>21</integer>

                                <key>ProcessingState</key>

                                <true/>

                            </dict>

                            <dict>

                                <key>Amp</key>

                                <dict>

This is the relevant part of the PathMap for me:

<dict>

                                <key>NodeID</key>

                                <integer>13</integer>

                            </dict>

                            <dict>

                                <key>Amp</key>

                                <dict>

                                    <key>Channels</key>

                                    <array>

                                        <dict>

                                            <key>Bind</key>

                                            <integer>1</integer>

                                            <key>Channel</key>

                                            <integer>1</integer>

                                        </dict>

                                        <dict>

                                            <key>Bind</key>

                                            <integer>2</integer>

                                            <key>Channel</key>

                                            <integer>2</integer>

                                        </dict>

                                    </array>

                                    <key>MuteInputAmp</key>

                                    <false/>

                                    <key>PublishMute</key>

                                    <true/>

                                    <key>PublishVolume</key>

                                    <true/>

                                    <key>VolumeInputAmp</key>

                                    <false/>

                                </dict>

                                <key>NodeID</key>

                                <integer>28</integer>

                            </dict>

                            <dict>

                                <key>NodeID</key>

                                <integer>27</integer>

                            </dict>

                            <dict>

                                <key>NodeID</key>

                                <integer>20</integer>

                            </dict>

See how Node 20 is at the bottom, and Node 13 at the top? In my edited Platforms12.xml I now have a path from Node 13 that can reach Node 20 and therefore I now have sound! (As shown in my first screenshot of OP, my internal speaker needs that path)

 

As a last resort if you can't seem to isolate which node you need to change/add, you can just copy the Platforms.xml + layout.xml that works for you in your injector you have and overwrite the layout[iD].xml.zlib and Platform[iD].xml.zlib with compressed versions of them in the AppleALC source yourself and recompile and that should work :)

 

I do highly recommend doing the codec graph part of the Mirone AppleHDA patching tutorial, as then you'll know what you need rather than just having to make sure you keep a copy of your known working layout+Platforms xmls! :D

Thanks very much will try. I contacted the AppleALC officials thread and apparently my revision of the IDT 76e0 wasn't added which was causing not working audio, but will see if yours is more compatible with my hardware.

 

Edit: OK so I tried your edited Platforms12.xml.zlib in my working AppleALC and I do still get sound. The one issue is only the bottom speakers work. Maybe your codec is different but on mine Node 15 is the top speakers and Node 13 is for the bottom as my laptop has four speakers in it. If your computer only has two speakers, that would explain why you didn't get audio output since your computer must be just using Node 13. So far nobody has found a way to enable both Node 13 and Node 15 so we will get 4 speakers working at the same time.

Link to comment
Share on other sites

 Share

×
×
  • Create New...