Open black-dragon74 opened 5 years ago
There exist similar issues in the bugtracker. Almost always they are caused by ACPI issues.
Thanks for the info Vit! I’ll do some debugging and report back.
Just an update. Tried by patching ACPI to remove unrelated stuffs related to HDAS (renamed to HDEF ofc). I also tried by removing the default HDAS device and injecting the new device HDEF
at the same _ADR
. The issue pertains. I am going to try by using a manually patched AppleHDA. Will keep you updated here. I have noticed there is a increase in this issue on the machines running latest version of Mojave. Also, @vit9696 anything specific related to ACPI that you would suggest me to try?
Thank You!
Last time I saw it it was caused by some weird device renaming for GPUs. Yes, for some reason Mojave is more peculiar about kext order, and the issue appears more frequently.
There was a logic fix here: https://github.com/acidanthera/bugtracker/issues/320, but really that bruteforce code should not trigger in the first place.
Yeah, I saw that. The latest version has that fix in place but the issue still exists. Been debugging for almost half of the day but still didn't get anything concrete. It is quite literally random.
Follow up: Tried by using fully patched AppleHDA. The same problem occurs. So, this clears on thing that this bug is not with the AppleALC but instead something has changed in the way macOS initializes the audio in AppleHDA. If anyone discovers anything please share it here.
@black-dragon74 i have same issue on my HP Elite 8300 SFF desktop. I just can't make my audio work on Open Core, everything else is perfect as it was with clover (but even faster with OpenCore). I tried every possible solution to the point of just using the bare minimum quirks to allow booting with minimal kexts and 0 acpi tables / acpi patches: Lilu, VirtualSMC, WhateverGreen, AppleALC, IntelMausi All this is to verify if device renaming causing it or something else. I just cant make audio work once, layout id hdef correct everything. I tested on one of my laptops and it's working. It seems to affect some codecs more than the others. Im my case is layout-id 11 realtek alc221
Terrible, but from the testing we did in the past I can only tell you that the issue is possible to reproduce with Clover, just it is much much rarer. It appears that the cause for it to not reproduce with Clover most of the time is much slower kext injection, which is basically done twice (in boot.efi and in XNU) and requires extra patches for 10.14+ slowing down things even more. It is mere seconds, but is enough.
As a workaround you could try adding keepsyms=1 boot argument. Sometimes it helps.
For me this issue has become quite annoying as the success to failure ratio is 2:10
Was looking at the AppleHDA binary to see if I could find any evidence or such change that is causing these issues but couldn’t.
It’s a bit saddening to see us getting nowhere despite trying so much but nonetheless let’s all keep trying till we get hold of the root cause of the problem.
P.S: @Snikii did audio work fine with Clover? Without above mentioned glitches?
Regards
@vit9696 correct, on my lenovo thinkpad L440 it happened on clover as well. Like every 30 boots/reboots it would happen, however it seems to affect some codecs or maybe acpi more than the other. On my HP Elite 8300 SFF it happened only once on clover so far. But with OpenCore didn't manage to get it working even once. What i would like to try just for testing purpose is to do a AppleALC.kext only with ALC221 resources and remove the rest just for testing purpose. I will try testing with keepsyms=1 and see if it works.
@black-dragon74 audio worked perfect with clover and still works. I used fixHPET in clover as without it it happened more often, however even on Open Core i patched HPET the same way but still no success.
I will try uploading logs and opencore efi folder just in case i have something wrong or missing, i tried to build the config.plist according to the documentation of opencore which is near perfect and easy to use.
I will do some more extended testing and report back with results.
I have just a small update: adding the PinConfigurations into DeviceProperties does show them loaded on IOREG but still no audio. However i do have some Steelseries Siberia V3 Prism, these are USB Headsets and the second i plug them the icon on menu bar becomes available immediately and audio works on these headsets.
But still no Speakers or jack output and mic inputs.
Will try more testing and tweaking tomorrow.
@Snikii Injecting PinConfig has been tried and yields no results.
The USB audio or the Bluetooth audio is completely different from analog audio and hence it works. You could try connecting AirPods to your machine. Both input and output channels will be available. But they will disappear as soon as you disconnect them.
Regards
@Snikii Injecting PinConfig has been tried and yields no results.
The USB audio or the Bluetooth audio is completely different from analog audio and hence it works. You could try connecting AirPods to your machine. Both input and output channels will be available. But they will disappear as soon as you disconnect them.
Regards
Unfortunately i still haven't managed to get the ALC221 codec to work once with Open Core on my HP Elite 8300 SFF. However i don't seem to have problems on my Lenovo V330-15IKB with Conexant CX20751_2 codec.
So it's true that it's affecting only specific codecs and not all of them.
My question now is does it have something to do with the patches failing to initiate:
<key>Patches</key>
<array>
<dict>
<key>Count</key>
<integer>1</integer>
<key>Find</key>
<data>xgYASIu/aAE=</data>
<key>MinKernel</key>
<integer>18</integer>
<key>Name</key>
<string>AppleHDA</string>
<key>Replace</key>
<data>xgYBSIu/aAE=</data>
</dict>
<dict>
<key>Count</key>
<integer>1</integer>
<key>Find</key>
<data>QcYGAEmLvCQ=</data>
<key>MaxKernel</key>
<integer>13</integer>
<key>MinKernel</key>
<integer>13</integer>
<key>Name</key>
<string>AppleHDA</string>
<key>Replace</key>
<data>QcYGAUmLvCQ=</data>
</dict>
<dict>
<key>Count</key>
<integer>1</integer>
<key>Find</key>
<data>QcYGAEiLu2g=</data>
<key>MinKernel</key>
<integer>14</integer>
<key>Name</key>
<string>AppleHDA</string>
<key>Replace</key>
<data>QcYGAUiLu2g=</data>
</dict>
<dict>
<key>Count</key>
<integer>1</integer>
<key>Find</key>
<data>QcaGQwEAAAA=</data>
<key>MinKernel</key>
<integer>12</integer>
<key>Name</key>
<string>AppleHDA</string>
<key>Replace</key>
<data>QcaGQwEAAAE=</data>
</dict>
<dict>
<key>Count</key>
<integer>2</integer>
<key>Find</key>
<data>YQLsEA==</data>
<key>MinKernel</key>
<integer>12</integer>
<key>Name</key>
<string>AppleHDA</string>
<key>Replace</key>
<data>AAAAAA==</data>
</dict>
<dict>
<key>Count</key>
<integer>2</integer>
<key>Find</key>
<data>hQjsEA==</data>
<key>MinKernel</key>
<integer>13</integer>
<key>Name</key>
<string>AppleHDA</string>
<key>Replace</key>
<data>AAAAAA==</data>
</dict>
<dict>
<key>Count</key>
<integer>2</integer>
<key>Find</key>
<data>hBnUEQ==</data>
<key>MinKernel</key>
<integer>12</integer>
<key>Name</key>
<string>AppleHDA</string>
<key>Replace</key>
<data>IQLsEA==</data>
</dict>
<dict>
<key>Count</key>
<integer>2</integer>
<key>Find</key>
<data>YgLsEA==</data>
<key>MinKernel</key>
<integer>12</integer>
<key>Name</key>
<string>AppleHDA</string>
<key>Replace</key>
<data>AAAAAA==</data>
</dict>
<dict>
<key>Count</key>
<integer>2</integer>
<key>Find</key>
<data>gxnUEQ==</data>
<key>MinKernel</key>
<integer>15</integer>
<key>Name</key>
<string>AppleHDA</string>
<key>Replace</key>
<data>AAAAAA==</data>
</dict>
<dict>
<key>Count</key>
<integer>2</integer>
<key>Find</key>
<data>hAjsEA==</data>
<key>MaxKernel</key>
<integer>14</integer>
<key>MinKernel</key>
<integer>12</integer>
<key>Name</key>
<string>AppleHDA</string>
<key>Replace</key>
<data>AAAAAA==</data>
</dict>
</array>
@black-dragon74 did you mention that you even tried complete patched AppleHDA without having to do the these patches by clover but in kext instead ?
@vit9696 and @black-dragon74 I finally managed to get audio working with OpenCore.
I tried with the available renames as mentioned on OpenCore Configuration.pdf for HPET fix but it didn't fix the issue although the patch worked (modified as needed by my ACPI set) I see that STA returns Noop but still no audio.
What i did is i added config.plist /Kernel/Block/ com.apple.driver.AppleHPET
As soon as i rebooted volume icon was non greyed out, and audio is working, also for some reasons, checking IOreg does still show AppleHPET loaded.
You may want to give this one a try @black-dragon74 just so we know for sure that it has no relation to AppleALC but rather a non-well configured ACPI as @vit9696 mentioned a few comments above.
Thanks
Off-Topic/Firm handshake note: holly crap the boot speed is nonsense/unbelievably fast with OC 0.0.4 + new AppleSupportPkg
The reason AppleHPET loads after blocking is most likely because it is not root required and kextd loads it afterwards from disk. This is best to be named a feature I guess.
The reason it works at all is not because AppleHPET is any relevant to the issue, but actually because you affect the loading order and timing in such a, well, barbaric way. You could replace AppleHPET with a dozen of other kexts and it will give you the same effect.
Given that OpenCore has nothing to do with that race condition bug in AppleHDA, as a workaround, this hack could work for the time being. Since AppleHDA is legacy and Apple will highly unlikely fix it, we could add some patch to AppleALC to make AppleHDA load with a user-configurable delay in some future.
@vit9696 @Snikii I can confirm that when you delay loading of AppleHDA somehow, the on-board audio works fine. I have tested it on 2 of my CFL laptops.
I managed to figure it out accidentally when cloning my installation to a SATA SSD from an NvME SSD. The SATA drive boots a bit slower than the NvME one (ofc) and the audio works 9 out of 10 times.
The custom delay approach would be the nice and will fix this issue for sure.
Regards
Off Topic: @vit9696 You might know that CLOVER fails to load on recent AMI Aptio V firmwares and EmuVariable is needed in order for it to load. Same init issue is present in the OpenCore except I can't use EmuVariable as it has no effect and is not meant to be used either. Any plans for adding support to Aptio V in OpenCore? I am facing this issue on my ASUS ROG and ASUS TUF gaming laptops.
@black-dragon74 thanks for confirming this.
You were right on how barbaric our setups used to be with Clover (good thing they can't scream when on such pain). When we switched to OpenCore that's when those issues came up in surface and we noticed how bad our patches used to be. I can't blame Clover completely for this, i may blame the extra tolerances on such cases but the core problem used to be on our side. I just recently cleaned up a lot of bloat from all my projects and will push changes into github (all this with Clover yet) when i switch these projects to OC it would be even more thanks to the cleaner approach.
Thanks for all @vit9696 and all other Acidanthera members.
Sincerely, Sniki
Have either of you tried to patch HPET, RTC, and TIMR IRQs in DSDT?
afaik, usually intermittent device initialization is caused by IRQ conflicts.
I’ve noticed this is commonly an issue with laptops.
I set HPET IRQNoFlags to 0,8 and removed them from RTC/TIMR to get my ALC233 working.
Have either of you tried to patch HPET, RTC, and TIMR IRQs in DSDT?
afaik, usually intermittent device initialization is caused by IRQ conflicts.
I’ve noticed this is commonly an issue with laptops.
I set HPET IRQNoFlags to 0,8 and removed them from RTC/TIMR to get my ALC233 working.
Yes i have tried and im aware of that. For me it's HPET on my HP Elite 8300 SFF Desktop and on my Lenovo ThinkPad X240.
But instead of touching those, if i am not mistaken, @vit9696 did mention that they plan to add a user customizable delay in the future, that should address this problem once and for all.
Huh, but id that's an ACPI issue, why do we need to add such workarounds? @rektimus may well be right about the correct approach to handle it.
@rektimus approach fixes the never working Audio codec, like i worked around the ALC221 on my HP Elite 8300 SFF. Although IRQ fixes make the codec work, there are still cases where it fails to load. Like every 20 boots, 1 time it will happen when you boot to have no audio. @black-dragon74 confirmed this as well, it does improve the problem, but doesn't complelety fix it. That's why i thought user customizable delay will be a complete problem solving case for the issue.
Huh, but id that's an ACPI issue, why do we need to add such workarounds? @rektimus may well be right about the correct approach to handle it.
@vit9696 so this pretty much wraps up the cause of the problem but what should be the best solution for this instead of having patched DSDT.aml into ACPI folder.
Shall we add a note into configuration.pdf > Troubleshooting: Audio is not working ? Kernel > Block > com.apple.driver.AppleHPET as a dirty barbaric workaround until a better solution comes out as I'm receiving same reports on Tony acx86 forum as well and suggesting them that dirty workaround Or:
Is it possible to implement an IRQfixes or FixIRQ Quirk to fix this problem ?
This may be out of topic but it's related to AppleALC as a suggestion. https://github.com/RehabMan/EAPD-Codec-Commander This kext is necessary on many codecs, it is currently working on but not being worked on (Rehabman seems to have left hackintosh work) I was thinking if it would be possible to merge it into AppleALC or port the project into Acidanthera ?
That's too bad to suggest.
I think so, but it needs the resources, which we are not ready to spend. If somebody submits a clean patch, we can consider it.
AppleALC fully supports command sending to the codec on both boot and wake as specified in PinConfigs.kext. I don't know why anybody still uses CodecCommander.
3. PinConfigs.kext. I don't know why anybody still uses CodecCommander.
i'm now using CodecCommander to fix extmic. but CC has problem that can't command hda-verb when booting. only work after sleep.
i want to use applealc feature to fix extmic.
https://github.com/acidanthera/AppleALC/blob/79526bc625f11e3cee6aaa379d65b2957c96a3c5/AppleALC/kern_alc.cpp#L368 auto configData = OSDynamicCast(OSData, config->getObject("ConfigData")); auto wakeConfigData = OSDynamicCast(OSData, config->getObject("WakeConfigData")); auto reinitBool = OSDynamicCast(OSBoolean, config->getObject("WakeVerbReinit"));
i need to command verb when boot and wakeup to command verb when booting, how can i add? just add like this?
<data>
AUcMAg==
</data>
<key>WakeConfigData</key>
<data>
AUcMAg==
</data>
<key>WakeVerbReinit</key>
<true/>
WakeConfigData WakeVerbReinit this part is good like CC. but still when boot, AppleALC command verb is not working compared to WakeConfigData+WakeVerbReinit combination.
maybe need BootVerbReinit? like WakeVerbReinit
EDIT1 AppleALC is no problem. i moved wakeconfigdata to configdata. everything is good
@vit9696 to be honest i wasn't aware that this feature is present on AppleALC, will check it tonight.
However there is another problem with ComboJack(s) (static noise on heaphones and no extmic "LineIn").
Goodwin created ALCPlugFix to fix that problem, menchen improved on it and i have my own fork for ALC3232 (aka ALC292) for ThinkPad laptops of Haswell generation and improved scripts.
Here is the link for reference: https://github.com/Sniki/ALCPlugFix
It would be awesome to have this integrated as well to have AppleALC as a all-in-one solution for Audio on every codec.
If you need it in other times than boot and wake currently it is unsupported. Otherwise just feed AppleALC with the verbs.
IOAudioEngine::setClockDomain is used by audio device driver to indicate whether this device is a clock master (by passing clockDomain = kIOAudioNewClockDomain), or synchronises to another audio engine (see IOAudioFamily IOAudioEngine.h). 0x737973 appears to be the clock domain for built-in audio devices (kIOAudioBuiltInSystemClockDomain in IOKit IOAudioTypes.h), so in Sierra some other IOAudioEngine's domain was used. This is probably because the logic in AppleHDA.kext changed. As a quick and dirty test, you could try using the Sierra's AppleHDA on Mojave to see if that fixes it.
On 10 Dec 2019, at 18:11, Daniel Stroe notifications@github.com wrote:
I observed one difference between ioreg's for the: IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/HDAU@3/AppleHDAController@3/IOHDACodecDevice@3,0/IOHDACodecDriver/IOHDACodecFunction@3,0,1/AppleHDACodecGeneric/AppleHDADriver/AppleHDAEngineOutputDP@3,0,1,0
for the working one (Sierra version): IOAudioEngineClockDomain = 0x4178f00
for the problematic one (Mojave): IOAudioEngineClockDomain = 0x737973
I wonder if this clock value difference could be the trouble with coreaudiod failing to work. Please advise!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
So I've been having the same issue recently on an XPS 15 9550. I'm not sure when it started happening but probably when I upgraded to Catalina. I tried messing with IRQs but to no avail. No matter what I did I always had something that felt like a 70% success rate. I added an IOSleep(1000) in onKextLoadForce and the success rate went back to 100%; this however of course slowed down the boot process to something feeling like way longer than a single second. Is there a better place where I could put a delay like that?
Can somebody test the attached debug version of AppleALC? On my Dell Inspiron 7590 it works so far. [AppleALC-1.4.7-DEBUG.zip] - updated version! (https://github.com/acidanthera/bugtracker/files/4275724/AppleALC-1.4.7-DEBUG.zip)
Can somebody test the attached debug version of AppleALC? On my Dell Inspiron 7590 it works so far. AppleALC-1.4.7-DEBUG.zip
I will give it a try tonight (at work right now, when i get back home) as both my ThinkPad T440S and X240 are affected by this problem.
Im still using this dirty workaround until the fix by: Blocking > com.apple.driver.AppleHPET which is somewhat delaying it and letting AppleALC.kext load. For me its due to IRQflags on HPET and IPIC.
Will let you know with results later today/tonight.
Thanks
Can somebody test the attached debug version of AppleALC? On my Dell Inspiron 7590 it works so far. AppleALC-1.4.7-DEBUG.zip
diff please?
@michyprima, I updated attached archive in my previous post, since that version caused high cpu usage by kernel_task.
Previous version was not reliable. I tried many places to put delay (even in IOHDACodecDevice::executeVerb + 5 attempts to retry). The only stable (at least on my machine) variant: delay AppleHDAController::start for 500 ms. Please give it a try. AppleALC-1.4.7-DEBUG.zip diff.patch.zip
@Shiyang-Wang confirmed that fix works.
Will build and test latest version and see what delay is enough for my case. The last one didn't work if 500ms was already specified into that build kext, or i had to add the delay ?
@Shiyang-Wang confirmed that fix works.
Will build and test latest version and see what delay is enough for my case. The last one didn't work if 500ms was already specified into that build kext, or i had to add the delay ?
Do you mean debug-version attached in this ticket? Try to build Apple Alc from master and set delay to 3000ms. After you can test and reduce this value.
以前的版本不可靠。我尝试了很多放置延迟的地方(即使在IOHDACodecDevice :: executeVerb中也尝试了5次重试)。 唯一稳定的变量(至少在我的机器上):将AppleHDAController :: start延迟500 ms。请试一试。 AppleALC-1.4.7-DEBUG.zip diff.patch.zip
cool !!!!
@Shiyang-Wang confirmed that fix works.
Will build and test latest version and see what delay is enough for my case.
The last one didn't work if 500ms was already specified into that build kext, or i had to add the delay ?
Do you mean debug-version attached in this ticket? Try to build Apple Alc from master and set delay to 3000ms. After you can test and reduce this value.
The delay didn’t work for me but i fixed it by patching HPET. Never happened for me anymore.
For me it’s solved (personally).
Thanks !
The delay didn’t work for me but i fixed it by patching HPET. Never happened for me anymore.
For me it’s solved (personally).
Thanks !
@Sniki - I tried your blocking approach and it's not working for me either.... HP 8300 DSDT machine running latest OpenCore and AppleALC 1.5.0
Did I do it right?
Did I do it right?
You have "Enabled 1" not "Enable". Fix it and try again.
@Sniki
The alcdelay boot arg also did not work for me blocking HPET works.
I have a Lenevo X1 Carbon 3rd Gen with i7 5600U which is very similar to your hardware. My audio codec is also ALC3232 ( ALC292). can you please share how you fixed your HPET? Thanks.
@MuhammadSheehab, did you try to specify higher values for alcdelay (3000 is maximum)?
i just use the one provided without changing anything, and everything is ok
发自我的iPhone
------------------ Original ------------------ From: lvs1974 <notifications@github.com> Date: Tue,Aug 18,2020 2:22 PM To: acidanthera/bugtracker <bugtracker@noreply.github.com> Cc: Shiyang-Wang <754806081@qq.com>, Mention <mention@noreply.github.com> Subject: Re: [acidanthera/bugtracker] AppleALC working intermittently (#422)
@MuhammadSheehab, did you try to specify higher values for alcdelay (3000 is maximum)?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
@MuhammadSheehab @Shiyang-Wang, @Sniki: you always have to start from the maximum value (3000) and check whether it works. If it works steadily, you can focus on minimising this delay.
@lvs1974 In my case, both my HP Elite 8300 SFF and my Lenovo ThinkPad(s) needed a patched HPET with NoIRQFlags to get audio working, the delay didn't work even on 3000ms
Also as @vit9696 previously said it's more like an ACPI problem.
Usually caused by HPET,IPIC,TMR,RTC But in general it mostly comes from HPET.
It can be easily fixed by using:
https://github.com/corpnewt/SSDTTime
It will generate/create the patched SSDT-HPET and the patch for Config.plist > ACPI > Patches >
The delay for AppleALC may work on some hardware but it didn't work on my current hardware. It did work on my Lenovo V330-15IKB which I don't have anymore as i sold that laptop. So the delay part is ok and works fine so i think there is nothing to do on the AppleALC side anymore
To be honest, i think this issue can be closed as for people who the delay don't work for them, they should fix their HPET/ACPI as it doesn't have to do anything with it.
Thanks !
@Sniki, in my case these patches did not help. Only with a delay it works. So it is probably hardware-related bug.
@Sniki, in my case these patches did not help. Only with a delay it works. So it is probably hardware-related bug.
Exactly,
Work done on your side works perfect on working cases, worked perfect on my Lenovo V330-15IKB and I believe there is nothing else to be done on AppleALC so i think this issue should be closed now.
Those who have problems, it’s ACPI related (like it was on my other Hardware)
Thanks !
@Sniki
For me delay did not work. I generated SSDT-HPET with SSDTime from linux. I added the generated SSDT-HPET.aml and patch to my OC but it did not work either.
Today, I saw your post about OC 5.9 guide for lenevo T440s in tonymacs and I used your SSDT and the patch to disable native HPET and finally the audio is working on my Lenevo X1 Carbon 3rd Gen.
Sniki, will it be possible for you to check my SSDT-HPET to see what was the problem?
SSDT-HPET generated by SSDTime: `/*
Compiler Version 0x20180105 (538444037) */ DefinitionBlock ("", "SSDT", 2, "CORP", "HPET", 0x00000000) { External (SB.PCI0.LPC_, DeviceObj) External (SB.PCI0.LPC_.HPET, DeviceObj)
Name (_SB.PCI0.LPC.HPET._CRS, ResourceTemplate () // _CRS: Current Resource Settings { IRQNoFlags () {0,8,11} Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) }
`
Hey, I would like to report an issue with the
AppleALC
project that I am facing since the very beginning on my hardware (ALC 295
). I didn't bring it up before as I wanted to test everything before opening an issue.The workings of the software is completely random. It sometimes works, sometimes doesn't. I have the logs from the event when it works and when it doesn't:
Logs when it doesn't work:
Logs when it works:
We can clearly see that for some reason
initializePinConfig
method is not being called. The result is no Audio input/output devices.The way to get back the audio is: Keep rebooting till you don't get it back. Which is a really dumb way to solve any problem. I have tried with all different layout IDs supported for
ALC295
. The result is the same.I have also tried with warm-booting and cold-booting. The results are exactly the same. Sometimes it works, sometimes it does not.
I have no other audio patches in place so there is no way anything else could be interfering with the workings of
AppleALC
I have tried every possible options and quirks and am not able to solve this. Hence this issue.
I would be glad to provide any help I could for further research.
Warmest Regards