<< Solved >> OpenCore battery patch

[takki]

@vettz500

How's your audio doing so far? I just read the following, click on the link and scroll to the bottom: https://dortania.github.io/OpenCore...ml#checking-if-applealc-is-patching-correctly

"Sometimes race conditions can occur where your hardware isn't initialized in time for AppleHDAController resulting in no sound output."

Maybe we can set alcdelay to f.e. 1000 and then get more consistent audio? It works pretty good for me so far, still interested if this may help. I know this is under the "desktop" section, but it probably also applies to laptops.

Wow nice find! I actually had a look when that part of the guide was added because I read the whole thing not too long ago and I swear there was nothing there. Sure enough it was added three days ago haha.

I also still have intermittent audio issues on some boots or when waking from sleep so I'll give this a try! I'm using alc-layout 29 btw, I guess you're using the same?

 

[BlvckBytes]

@takki

Yup, also on layout 29, but I didn't apply this delay yet, since I'm working on a second small hackintosh project rn. But I will do so next time the laptop gets booted up, then I'll check for no-audio boots or speaker-issues.

 

[takki]

@takki

Yup, also on layout 29, but I didn't apply this delay yet, since I'm working on a second small hackintosh project rn. But I will do so next time the laptop gets booted up, then I'll check for no-audio boots or speaker-issues.

I just added it to my config. Using a 1000ms delay for now, I really hope it fixes the issue.

Edit: Did a couple restarts, so far so good!

 

[BlvckBytes]

@takki

I added it too rn. As I already stated, my audio works great most of the time. Also, from my experience, if you don't really *cold* start (means like min. 30 min off), those errors appear with a far less probability. So only a few days of checking will tell if it actually helps. I hope the best for you!

 

[vettz500]

@vettz500

How's your audio doing so far? I just read the following, click on the link and scroll to the bottom: https://dortania.github.io/OpenCore...ml#checking-if-applealc-is-patching-correctly

"Sometimes race conditions can occur where your hardware isn't initialized in time for AppleHDAController resulting in no sound output."

Maybe we can set alcdelay to f.e. 1000 and then get more consistent audio? It works pretty good for me so far, still interested if this may help. I know this is under the "desktop" section, but it probably also applies to laptops.

If I don't boot into Windows, audio works perfect 100% of the time across every reboot, shutdown and sleep cycle. If I boot into Windows, I just have to make sure it's for a few minutes and then check that Windows volume is set to 100% and then it'll be good when I reboot into OSX.

I'll look into that link you just posted though. Could be the fix for after booting into Windows.

 

[codeVerine]

@BlvckBytes

I hope you remember me. Finally I was able to find the culprit behind my broken battery status. It was not an issue with SSDT-BAT or the SMC kext. My SSDT-EC-USBX was disabling EC0 inside it and it broke my battery status.

Scope (\_SB.PCI0.LPCB.EC0)
    {
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (_OSI ("Darwin"))
            {
                Return (Zero)
            }
            Else
            {
                Return (0x0F)
            }
        }
    }

Now I'm wondering why it does this. I'm thinking commenting these line would cause any issue related to USB power management.

 

[takki]

@BlvckBytes

I hope you remember me. Finally I was able to find the culprit behind my broken battery status. It was not an issue with SSDT-BAT or the SMC kext. My SSDT-EC-USBX was disabling EC0 inside it and it broke my battery status.

Scope (\_SB.PCI0.LPCB.EC0)
    {
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (_OSI ("Darwin"))
            {
                Return (Zero)
            }
            Else
            {
                Return (0x0F)
            }
        }
    }

Now I'm wondering why it does this. I'm thinking commenting these line would cause any issue related to USB power management.

You are right, the EC (Embedded Controller) does deal with the battery. The problem is that macOS needs the EC to be present at EC and not EC0. There should be another part where a new EC device is created, otherwise your system wouldn't boot. Depending on how you did the battery patch and what the whole of SSDT-EC-USBX looks like, there could be a conflict with the name of the EC device.

Usually on desktops the original EC device is disabled, because it can cause trouble if you just rename it from EC0 to EC, although on laptops that can sometimes help to get things working. The most recommended way to do it now seems to be leaving EC0 as is and just adding a dummy EC device so macOS doesn't complain. Here is a guide regarding EC. Take a look at SSDT-EC-USBX-LAPTOP.

If you want more in depth help, please upload your EFI folder or even better, use gen_debug to generate debugging files. Also please attach the output of the following command:

log show --predicate "processID == 0" --last 24h --debug | grep -i  AppleACPIPlatform

 

[BlvckBytes]

@codeVerine

I sure do . In my case, I found a native and working EC0, that I just rename to EC and then made sure that all fake ec code got removed.

Then, SSDT-BATT needs to reference EC ofc, not EC0. Please attach your latest EFI and I will try to help you tonight.

 

[takki]

@codeVerine

I sure do . In my case, I found a native and working EC0, that I just rename to EC and then made sure that all fake ec code got removed.

Then, SSDT-BATT needs to reference EC ofc, not EC0. Please attach your latest EFI and I will try to help you tonight.

As far as I understand, it's still safer and more stable to keep EC0 as EC0 and create a dummy EC device. See the guide I linked above. If you did your USB mapping with hackintool and chose the SSDT method, then there will already be a dummy EC device in SSDT-EC-USBX.

If you go the dummy EC route, then all SSDTS that so something to the EC need to reference the original EC0 device and not EC. So battery patches need to reflect that and in my case the RTEC patch as well.

Also a small update on audio: unfortunately I didn't have sound again after an overnight sleep cycle. Weirdly booting to windows doesn't affect audio like it does in @vettz500 case, it's more of a random thing when rebooting or using sleep. Yesterday I switched to alc-layout 3 and so far it works perfectly. Audio was there after sleep and I rebooted a fair number of times. Still needs more testing though.

On another note, did you use voltageshift to undervolt? I'm stable at -140 -40 -140 but it's a little unclear how to make the launchdaemon work since the number of parameters in the documentation differs from the examples in there.

 

[BlvckBytes]

@takki

I just altered my USBX to fit the new EC device, so far I don't want to use the fake stuff, since it works out nicely.

Yes, I use voltageshift. It was something along the lines of buildlaunchd, I think, I'll also have to look that up tonight, since I'm not on my laptop rn.

Please tell me if layout id 3 works for you in the long run, after some days. Jack and speakers working fine too?