AppleALC - Need help on custom layout for ALC255

[swissblade27]

hello, i recently made a custom layout for my laptop (layout=69 in ALC255) and it got merged into the main repo. i had an annoying issue with my layout (headsets produced white noise when the power state changed from AC to BAT), but i recently fixed it with new ConfigData and i will make a new pull request to main repo.

 

now i have another strange problem. after the computer sleeps and wakes up, when the internal microphone (node 0x12) is used and after it enters sleep state, headsets (node 0x19) no longer produce sound after some time. i need to unplug and then plug headsets back in order to get working sound. they continue to work even if internal microphone enters sleep state after unplugging & plugging procedure. this problem also doesn't happen on cold boot.

 

can anyone help me solve this problem? this is the only remaining bug in my hackintosh

 

my laptop specs and EFI: https://github.com/juniorcaesar/OC-A315-56-327T

my cloned AppleALC repo: https://github.com/juniorcaesar/AppleALC

 

pin control states in my config, current configdata, and codec dumps from linux & opencore are attached below.

 

thanks in advance!

linux_card0-codec#0.txt opencore_Codec0.txt PinConfig.rtf

[miliuco]

@swissblade27

 

I hope that this site helps you.

[swissblade27]

7 minutes ago, miliuco said:

@swissblade27

 

I hope that this site helps you.

 

thanks, but i made my layout thanks to this awesome guide  and unfortunately my issue is not covered here. i also made some research on the internet but couldn't find any help.

[theroadw]

I'm running a "similar" problem with my laptop alc256 - layout 13, everything works but after sleep kernel process uses 50% CPU and power log show its applehda interrupts. So I made a new layout and if I remove the mic in node, everything is happy before and after sleep, but everything I've tried keeping the plug (headset) mic enabled creates glitches.

If I reinit all or some of the the eapd nodes then the input defaults to line in, and I have to change the coefficients to change back to built in mic default, but now the problem is there is an idle sleep preventing task with apple hdef output, if I don't reinit the nodes, then high kernel activity.

I've compared the coefficients using this method.

 

https://github.com/acidanthera/AppleALC/wiki/Dumping-processing-coefficients

 

And they are mostly the same before and after sleep. Only one changed coefficient and changing it only makes input go back to internal mic, but sleep issue is still there.

 

Just can't figure out why if I have a plug-in mic node present there are kernel or sleep issues.

 

I've tried resetting the codec using the values for reset sleep/wake in https://github.com/hackintosh-stuff/ComboJack

But it only changes the input to internal mic on wake but the sleep issue persists.

 

Maybe some of the stuff I've tried will help you, or someone who knows more can help us?

Edited February 17 by theroadw
Adding more information

[Slice]

What do you prefer to stay without sound or to try voodoohda?

[swissblade27]

21 hours ago, theroadw said:

I'm running a "similar" problem with my laptop alc256 - layout 13, everything works but after sleep kernel process uses 50% CPU and power log show its applehda interrupts. So I made a new layout and if I remove the mic in node, everything is happy before and after sleep, but everything I've tried keeping the plug (headset) mic enabled creates glitches.

If I reinit all or some of the the eapd nodes then the input defaults to line in, and I have to change the coefficients to change back to built in mic default, but now the problem is there is an idle sleep preventing task with apple hdef output, if I don't reinit the nodes, then high kernel activity.

I've compared the coefficients using this method.

 

https://github.com/acidanthera/AppleALC/wiki/Dumping-processing-coefficients

 

And they are mostly the same before and after sleep. Only one changed coefficient and changing it only makes input go back to internal mic, but sleep issue is still there.

 

Just can't figure out why if I have a plug-in mic node present there are kernel or sleep issues.

 

I've tried resetting the codec using the values for reset sleep/wake in https://github.com/hackintosh-stuff/ComboJack

But it only changes the input to internal mic on wake but the sleep issue persists.

 

Maybe some of the stuff I've tried will help you, or someone who knows more can help us?

 

thank you for your response! i decided to use the internal mic because whenever i send the verbs to enable headset mic, there will be popping sounds when any sound is playing which is super annoying.

however, applealc acts even more weird now on my computer. even though the headsets didn't produce glitched sound when the power state changed from AC to BAT with my latest changes, i left my computer powered off for 2 weeks and they broke again. i really have no idea what causes those problems in the first place, guess our codecs need some special treatment  

for now, headset works properly when i put my computer into sleep and wake it after 4-5 seconds. when i send the wake-up verbs with alc-verb (01470c02 02170c02 02170883 01970722) it doesn't get fixed. it's super annoying (i've been trying to fix this problem since november) and i don't know what to do honestly. maybe it has to do something with my EFI.

 

18 hours ago, Slice said:

What do you prefer to stay without sound or to try voodoohda?

 

i can try voodoohda if i can't fix these problems since i want native audio. do "restricted enabled SIP" cause any inconveniences in the system?

[theroadw]

I don't want to jinx it, but I believe I may have fixed mine, I removed EAPD from all but the speaker node and I'm just waking the speaker node. Then I added to my sleepwatcher script

cd /usr/local/sbin
./hda-verb 0x20 0x500 0x1b
./hda-verb 0x20 0x400 0x0c4b

And the input reverts back to internal Mic input.

Speaker works, headphones and headset selection work, no sleep issues, no high kernel process so far.
So just need to do more tests on longer sleeps, and see if all nodes are behaving correctly after those and multiple sleep/wake cycles.

 

@swissblade27are you using Combojack or ALCPlugFix-Swift to automate plug behavior?

 

edit:

After many more tests, and even warm reboot from windows, everything seems to be working correctly, so looks like my solution was to send those control coefficients.

Edited February 18 by theroadw

[Slice]

3 hours ago, swissblade27 said:

 

i can try voodoohda if i can't fix these problems since i want native audio. do "restricted enabled SIP" cause any inconveniences in the system?

What is native audio? Is it hackintosh? "Native" for Apple's chip? No, you have not. You have third party chip and may use third party driver which works much better then native applehda.

[swissblade27]

On 2/18/2023 at 4:44 PM, theroadw said:

I don't want to jinx it, but I believe I may have fixed mine, I removed EAPD from all but the speaker node and I'm just waking the speaker node. Then I added to my sleepwatcher script

cd /usr/local/sbin
./hda-verb 0x20 0x500 0x1b
./hda-verb 0x20 0x400 0x0c4b

And the input reverts back to internal Mic input.

Speaker works, headphones and headset selection work, no sleep issues, no high kernel process so far.
So just need to do more tests on longer sleeps, and see if all nodes are behaving correctly after those and multiple sleep/wake cycles.

 

@swissblade27are you using Combojack or ALCPlugFix-Swift to automate plug behavior?

 

edit:

After many more tests, and even warm reboot from windows, everything seems to be working correctly, so looks like my solution was to send those control coefficients.

 

glad that you fixed your problem   and no i don't use any automated programs / daemons to send verbs because my problem only appears after unplugging AC power (which programs like ALCPlugFix-Swift does not have support for.) however, i found the culprit.

 

it seems like my codec sends verbs depending on the power state to change the VREF values of the nodes (specifically 0x19 (Line-In)), as you can see in the screenshot below. fresh boot assigns the Pin Sense of 0x19 to 0x22 (i believe that's the value for VREF_50.) on AC power, when no sound is playing and / or there's a continuous playback, this value gets replaced by 0x24 (VREF_80). this seems nice and all but when i pull out the charger, all hell breaks loose; after approximately 2+ minutes of silence, Pin Sense of 0x12 (Internal Mic), 0x21 (Headphones) resets to 0x00 and 0x19 resets to 0x02, resulting in white noise. when i remove the headset at this point, my laptop can't detect the change and doesn't switch to the speakers. 

 

this problem gets solved when i send the verb 0x19 0x707 0x22.

 

i tried sending the changed coefs according to the linux dump but they have no effect.

 

i use Apple EarPods as the headset. i have no idea what causes this, i tried adding AFGLowPowerState entry in my config.plist but it didn't help. any help is appreciated!

 

 

Edited February 22 by swissblade27

[theroadw]

That is very weird, reminds me of my Zbook G5 problem, using AppleALC everything worked but on wake from sleep, the speaker would play for 10 seconds and then go silent. switching outputs would get me speaker again for another 10 seconds then silence. It was very annoying and couldn't figure it out, ended up using VoodooHDA.

Seeing the details of your problem gave me some ideas as to what could be happening on the Zbook.

 

Have you looked in your DSDT at device _AC to see if power change notifications get sent to HDEF or so?

 

I guess this doesn't happen in Linux or Windows, so maybe use debug versions of smcbattery, virtualsmc, lilu, applealc, etc... and maybe in console something may log a power state change error or something?

[swissblade27]

10 hours ago, theroadw said:

That is very weird, reminds me of my Zbook G5 problem, using AppleALC everything worked but on wake from sleep, the speaker would play for 10 seconds and then go silent. switching outputs would get me speaker again for another 10 seconds then silence. It was very annoying and couldn't figure it out, ended up using VoodooHDA.

Seeing the details of your problem gave me some ideas as to what could be happening on the Zbook.

 

Have you looked in your DSDT at device _AC to see if power change notifications get sent to HDEF or so?

 

I guess this doesn't happen in Linux or Windows, so maybe use debug versions of smcbattery, virtualsmc, lilu, applealc, etc... and maybe in console something may log a power state change error or something?

 

i don't have any HDEF device in my DSDT. i looked at the EC0 section but couldn't find any reference to the audio changes. and no i don't have any issues in Linux or in Windows. i will attach my DSDT files if you want to take look at it.

 

i want to add that i tried using the pin configs that are used in Linux in my custom layout but it doesn't change anything.

 

anyways, i started watching logs on Console application and as i suspected, kernel gives command to the IOAudioDevice to change its power state when it's not in use. at that point, all 4 pin senses resets to 0x00 / 0x02 and headset produces garbled / white noise.

 

do debug versions of the kexts that you mentioned log what's happening when i use macOS, rather than on the OpenCore boot sequence? if that's the case, i will try that also.

 

 

DSDT.aml DSDT.dsl

[theroadw]

I can see that under device ACAD (AC power plug) you have OSYS dependent calls, but in your config you're patching OSI calls correctly, also on HDAS (Sound) you have the potentially troublesome (GPRW)  0x6D, 0x04e where MacOS expects 0x6D, 0x00. But I believe these are all red herrings, I bet it's a power state change triggered by AppleHDA directly that is somehow messing with the codec directly, I would try Combojack's reset patches.

 

OR

 

 

 

Can you share you pin_ctrl_dump script to do some tests on my zbook?

 

Edited February 24 by theroadw

[swissblade27]

first of all, thank you for your help! 

 

1 hour ago, theroadw said:

also on HDAS (Sound) you have the potentially troublesome (GPRW)  0x6D, 0x04e where MacOS expects 0x6D, 0x00. 
 

 

i do have an GPRW to XPRW patch enabled, but when i check the System DSDT, it doesn't appear to be patched (i don't know if it's supposed to, I'm kinda new to the hackintosh scene )

 

 

1 hour ago, theroadw said:

But I believe these are all red herrings, I bet it's a power state change triggered by AppleHDA directly that is somehow messing with the codec directly, I would try Combojack's reset patches.

 

 

i tried using ComboJack's patches via alc-verb couple months ago and i believe these commands are used to reset the microphone detection on the headsets as these commands enable EarPods':

 

 

however, when i send these verbs headset produces loud pop sound whenever a sound is playing so i prefer not to use headset's mic and not to send those verbs (as internal mic works "fine"). 

 

also, in the first screenshot you posted,  i have no idea what "1<<14" part stands for in the "WRITE_COEFEX" command so i couldn't send it before.

as for the second screenshot, i already use those verbs to enable pin sense for Line-In (0x19) (i just use lower VREF value as it's assigned on BAT power / cold boot, 22 instead of 24) and headphone detection (0x21) in my layout:

 

 

i attached the script that i use, it's made by @wern apfel as far as i'm aware, i found it somewhere on the internet and just renamed a section to use alc-verb instead of hda-verb. all rights goes to them  

pin_ctrl_dump_mod.sh

[swissblade27]

so i made couple of tests and here's what i've found:

 

1-) i found out that changing VREF values are set by the MuteGPIO value on layout-xx.xml file. i had the VREF_80 value for the Pin 25 (0x19) as MuteGPIO, so whenever i plug in the charger, it was resetting the Pin-ctrl for 0x19 to 24. somehow setting MuteGPIO value to VREF_80+ Pin 24 (0x18) solved this problem, my VREF values stay unchanged on AC power. however this didn't solve the garbled sound problem because the sound nodes goes to sleep (as they are unused after AC power) nonetheless. i believe that's the intended behavior of AppleHDA. 

 

2-) i tried disabling unnecessary SSDT patches, including FixHPET (only enabled the essential ones.) it didn't make a difference.

 

3-) i tried enabling alc-delay argument (1000 and 3000), it didn't make a difference.

 

4-) i tried another layout (71), either that or something else set new Pin-ctrls on fresh boot (0x19's Pin Widget Control was 0x22, now it's 0x20 regardless of layout.) unfortunately, same garbled sound problem exists here. 

 

5-) i tried using Node 24 (0x18) as the Line-In, but it resulted in unbalanced audio (i don't know how to describe it honestly. it sounds like if you plugged in an unsupported 4 pole headset into 3 pin headphone jack.) so i went back to using 0x19 as Line-In.

i should note something important here. if i send "alc-verb 0x19 0x707 0x20/21/22/24" here, Node 25 (0x19) does not go to sleep regardless of the power state (AC or BAT). it stays powered up, so no sound problems arise.

 

 

i tried sending that same verb manually on my normal pin-config but it doesn't solve the problem.

 

6-) i tried adding Node 24 (0x18) and 26 (0x1A) alongside Node 25 (0x19, set as the Line-In). it didn't solve the problem and made it much worse (in this instance, speakers produced that garbled sound  ).

 

7-) i tried tweaking Amp values in Platforms-69.xml (MuteInputAmp, PublishMute, ...) but i believe it didn't change anything. there are no clear explanation on what they do, or to what values should they be set according to the codec dump (different tutorials say different things about them.)

 

8-) i tried using the Pin configs that are used in Linux, same result.

 

 

 

So in summary, this problem is neither related to the pin configs, nor the layout or platforms.xml. when i send one of the following verbs:

 

alc-verb 0x19 0x707 0x00

alc-verb 0x19 0x707 0x01

alc-verb 0x19 0x707 0x02

 

they all produce that garbled sound. when i send:

 

alc-verb 0x19 0x707 0x20

alc-verb 0x19 0x707 0x21

alc-verb 0x19 0x707 0x22

alc-verb 0x19 0x707 0x24

 

then the sound works properly.

 

somehow i need to keep the Node 25 alive regardless of the power state of the laptop, in order to keep my ears from tinnitus . unfortunately i couldn't find anything regarding this.

 

EDIT: FIXED (kinda), see my reply below.

 

 

Edited March 2 by swissblade27
removed the tag, removed misinformation

[swissblade27]

I FIXED IT! 

 

Well, sort of...

 

On 2/28/2023 at 11:16 PM, swissblade27 said:

5-) i tried using Node 24 (0x18) as the Line-In, but it resulted in unbalanced audio (i don't know how to describe it honestly. it sounds like if you plugged in an unsupported 4 pole headset into 3 pin headphone jack.) so i went back to using 0x19 as Line-In.

i should note something important here. if i send "alc-verb 0x19 0x707 0x20/21/22/24" here, Node 25 (0x19) does not go to sleep regardless of the power state (AC or BAT). it stays powered up, so no sound problems arise.

 

I was right, when a node doesn't exist in the PinConfig.kext, Platforms.xml and layout.xml files, it's powered down infinitely since AppleALC doesn't send its verbs and specs to AppleHDA to initiate it. I did remove Line-In connection entirely on Pin configs, layout69.xml, Platforms69.xml (Node 25) and when i send "alc-verb 0x19 0x707 0x24", it stays powered up across all power states and sound works perfectly! However, when I add the verb "01970724" to the PinConfigs it doesn't get applied. In that instance, Pin Control Widget of Node 25 becomes 0x04, I don't know why. 

 

With this new config I tried ComboJack again, but that popping sound problem was still there when nodes are activated after macOS turns them off (this doesn't happen on Linux btw, all of the amps stay powered up all the time.) I couldn't use the headset mic anyway so I deleted it.

 

Instead, I use ALCPlugFix-Swift to automate that verb sending process, so far so good. It sends the verb when the system boots and wakes up.

 

Additionally, I needed to add the verb 02170883 to my PinConfig & WakePinConfig in order to get headphone detection working.

 

This forum post also confirms my findings: https://www.hackintosh-forum.de/forum/thread/55405-alc255-combo-jack-mittels-codec-dump-fixen-acer-aspire-5-a515-51g-512p/?pageNo=1

 

 

 

 

Finally, I can finally enjoy my music without any interruptions!...

 

... Or so I thought.

 

 

Now, I have the exact same problem in the first post, again!

 

On 1/22/2023 at 5:49 PM, swissblade27 said:

after the computer sleeps and wakes up, when the internal microphone (node 0x12) is used and after it enters sleep state, headphones (Pin 0x21, Node 33*) no longer produce sound after some time. i need to unplug and then plug the headphone back in order to get working sound. they continue to work even if internal microphone enters sleep state after unplugging & plugging procedure. this problem also doesn't happen on cold boot.

 

I looked at the changed coeffs in Node 0x20 but sending the correct ones doesn't bring the sound back. I tried tweaking Amp values in the Platforms69.xml, but it has no effect.

 

I don't know what Acer was thinking when they manufactured this exact model or why they put this specific janky ComboJack, but I don't like it a bit  

 

 

Platforms69.xml layout69.xml ALC255.plist Verbs.rtf

Edited March 2 by swissblade27
Fixed typos & added files