acidanthera / bugtracker

Acidanthera Bugtracker
385 stars 45 forks source link

AppleALC working intermittently #422

Open black-dragon74 opened 5 years ago

black-dragon74 commented 5 years ago

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:

AppleALC:    init @ (DBG) AppleALC bootstrap DBG-139-2019-07-03
AppleALC:   iokit @ (DBG) getOSData vendor-id has 8086 value
AppleALC:   iokit @ (DBG) getOSData device-id has A170 value
AppleALC:   iokit @ (DBG) getOSData revision-id has 10 value
AppleALC:   iokit @ (DBG) getOSData alc-layout-id has E value
AppleALC:     alc @ (DBG) found 2 audio controllers
AppleALC:     alc @ (DBG) validating 0 controller 8086:3E9B:0
AppleALC:     alc @ (DBG) comparing to 0 mod 8086:9DC8
AppleALC:     alc @ (DBG) comparing to 1 mod 8086:A2F0
AppleALC:     alc @ (DBG) comparing to 2 mod 8086:A348
AppleALC:     alc @ (DBG) comparing to 3 mod 8086:A171
AppleALC:     alc @ (DBG) comparing to 4 mod 8086:8D21
AppleALC:     alc @ (DBG) comparing to 5 mod 8086:8D20
AppleALC:     alc @ (DBG) comparing to 6 mod 8086:F04
AppleALC:     alc @ (DBG) comparing to 7 mod 8086:24
AppleALC:     alc @ (DBG) comparing to 8 mod 8086:C0C
AppleALC:     alc @ (DBG) comparing to 9 mod 8086:8D20
AppleALC:     alc @ (DBG) comparing to 10 mod 8086:A171
AppleALC:     alc @ (DBG) comparing to 11 mod 1002:AAC8
AppleALC:     alc @ (DBG) comparing to 12 mod 1002:AB08
AppleALC:     alc @ (DBG) comparing to 13 mod 10DE:E0F
AppleALC:     alc @ (DBG) comparing to 14 mod 10DE:10EF
AppleALC:     alc @ (DBG) comparing to 15 mod 10DE:10F1
AppleALC:     alc @ (DBG) comparing to 16 mod 10DE:FBA
AppleALC:     alc @ (DBG) comparing to 17 mod 10DE:FB0
AppleALC:     alc @ (DBG) comparing to 18 mod 10DE:FBB
AppleALC:     alc @ (DBG) comparing to 19 mod 10DE:FB8
AppleALC:     alc @ (DBG) comparing to 20 mod 10DE:FB9
AppleALC:     alc @ (DBG) comparing to 21 mod 10DE:10F0
AppleALC:     alc @ (DBG) comparing to 22 mod 10DE:FBC
AppleALC:     alc @ (DBG) comparing to 23 mod 1022:1457
AppleALC:     alc @ (DBG) comparing to 24 mod 1022:15E3
AppleALC:     alc @ (DBG) validating 1 controller 8086:A170:10
AppleALC:     alc @ (DBG) comparing to 0 mod 8086:9DC8
AppleALC:     alc @ (DBG) comparing to 1 mod 8086:A2F0
AppleALC:     alc @ (DBG) comparing to 2 mod 8086:A348
AppleALC:     alc @ (DBG) comparing to 3 mod 8086:A171
AppleALC:     alc @ (DBG) comparing to 4 mod 8086:8D21
AppleALC:     alc @ (DBG) comparing to 5 mod 8086:8D20
AppleALC:     alc @ (DBG) comparing to 6 mod 8086:F04
AppleALC:     alc @ (DBG) comparing to 7 mod 8086:24
AppleALC:     alc @ (DBG) comparing to 8 mod 8086:C0C
AppleALC:     alc @ (DBG) comparing to 9 mod 8086:8D20
AppleALC:     alc @ (DBG) comparing to 10 mod 8086:A171
AppleALC:     alc @ (DBG) comparing to 11 mod 1002:AAC8
AppleALC:     alc @ (DBG) comparing to 12 mod 1002:AB08
AppleALC:     alc @ (DBG) comparing to 13 mod 10DE:E0F
AppleALC:     alc @ (DBG) comparing to 14 mod 10DE:10EF
AppleALC:     alc @ (DBG) comparing to 15 mod 10DE:10F1
AppleALC:     alc @ (DBG) comparing to 16 mod 10DE:FBA
AppleALC:     alc @ (DBG) comparing to 17 mod 10DE:FB0
AppleALC:     alc @ (DBG) comparing to 18 mod 10DE:FBB
AppleALC:     alc @ (DBG) comparing to 19 mod 10DE:FB8
AppleALC:     alc @ (DBG) comparing to 20 mod 10DE:FB9
AppleALC:     alc @ (DBG) comparing to 21 mod 10DE:10F0
AppleALC:     alc @ (DBG) comparing to 22 mod 10DE:FBC
AppleALC:     alc @ (DBG) comparing to 23 mod 1022:1457
AppleALC:     alc @ (DBG) comparing to 24 mod 1022:15E3
AppleALC:     alc @ (DBG) missing ControllerModInfo for 0 controller
AppleALC:     alc @ (DBG) missing ControllerModInfo for 1 controller
AppleALC:     alc @ (DBG) found analog codec IOHDACodecDevice
AppleALC:     alc @ (DBG) storing codec info for 10EC:295:100002
AppleALC:     alc @ failed to find IOHDACodecVendorID, retrying 0
AppleALC:     alc @ (DBG) found supported Realtek ALC295 codec revision 0x100002
AppleALC:     alc @ (DBG) missing ControllerModInfo for 0 controller
AppleALC:     alc @ (DBG) missing ControllerModInfo for 1 controller
AppleALC:     alc @ (DBG) will route resource loading callbacks
AppleALC:     alc @ (DBG) checking patch 0 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 0  for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 1 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 2 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 2  for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 3 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 3  for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 4 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 4  for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 5 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 5  for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 6 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 6  for 9 kext (com.apple.driver.AppleHDAkernel) 
AppleALC:     alc @ (DBG) checking patch 7 for 9 kext (com.apple.driver.AppleHDA)

Logs when it works:

AppleALC:    init @ (DBG) AppleALC bootstrap DBG-139-2019-07-03
AppleALC:   iokit @ (DBG) getOSData vendor-id has 8086 value
AppleALC:   iokit @ (DBG) getOSData device-id has A170 value
AppleALC:   iokit @ (DBG) getOSData revision-id has 10 value
AppleALC:   iokit @ (DBG) getOSData alc-layout-id has E value
AppleALC:     alc @ (DBG) found 2 audio controllers
AppleALC:     alc @ (DBG) validating 0 controller 8086:3E9B:0
AppleALC:     alc @ (DBG) comparing to 0 mod 8086:9DC8
AppleALC:     alc @ (DBG) comparing to 1 mod 8086:A2F0
AppleALC:     alc @ (DBG) comparing to 2 mod 8086:A348
AppleALC:     alc @ (DBG) comparing to 3 mod 8086:A171
AppleALC:     alc @ (DBG) comparing to 4 mod 8086:8D21
AppleALC:     alc @ (DBG) comparing to 5 mod 8086:8D20
AppleALC:     alc @ (DBG) comparing to 6 mod 8086:F04
AppleALC:     alc @ (DBG) comparing to 7 mod 8086:24
AppleALC:     alc @ (DBG) comparing to 8 mod 8086:C0C
AppleALC:     alc @ (DBG) comparing to 9 mod 8086:8D20
AppleALC:     alc @ (DBG) comparing to 10 mod 8086:A171
AppleALC:     alc @ (DBG) comparing to 11 mod 1002:AAC8
AppleALC:     alc @ (DBG) comparing to 12 mod 1002:AB08
AppleALC:     alc @ (DBG) comparing to 13 mod 10DE:E0F
AppleALC:     alc @ (DBG) comparing to 14 mod 10DE:10EF
AppleALC:     alc @ (DBG) comparing to 15 mod 10DE:10F1
AppleALC:     alc @ (DBG) comparing to 16 mod 10DE:FBA
AppleALC:     alc @ (DBG) comparing to 17 mod 10DE:FB0
AppleALC:     alc @ (DBG) comparing to 18 mod 10DE:FBB
AppleALC:     alc @ (DBG) comparing to 19 mod 10DE:FB8
AppleALC:     alc @ (DBG) comparing to 20 mod 10DE:FB9
AppleALC:     alc @ (DBG) comparing to 21 mod 10DE:10F0
AppleALC:     alc @ (DBG) comparing to 22 mod 10DE:FBC
AppleALC:     alc @ (DBG) comparing to 23 mod 1022:1457
AppleALC:     alc @ (DBG) comparing to 24 mod 1022:15E3
AppleALC:     alc @ (DBG) validating 1 controller 8086:A170:10
AppleALC:     alc @ (DBG) comparing to 0 mod 8086:9DC8
AppleALC:     alc @ (DBG) comparing to 1 mod 8086:A2F0
AppleALC:     alc @ (DBG) comparing to 2 mod 8086:A348
AppleALC:     alc @ (DBG) comparing to 3 mod 8086:A171
AppleALC:     alc @ (DBG) comparing to 4 mod 8086:8D21
AppleALC:     alc @ (DBG) comparing to 5 mod 8086:8D20
AppleALC:     alc @ (DBG) comparing to 6 mod 8086:F04
AppleALC:     alc @ (DBG) comparing to 7 mod 8086:24
AppleALC:     alc @ (DBG) comparing to 8 mod 8086:C0C
AppleALC:     alc @ (DBG) comparing to 9 mod 8086:8D20
AppleALC:     alc @ (DBG) comparing to 10 mod 8086:A171
AppleALC:     alc @ (DBG) comparing to 11 mod 1002:AAC8
AppleALC:     alc @ (DBG) comparing to 12 mod 1002:AB08
AppleALC:     alc @ (DBG) comparing to 13 mod 10DE:E0F
AppleALC:     alc @ (DBG) comparing to 14 mod 10DE:10EF
AppleALC:     alc @ (DBG) comparing to 15 mod 10DE:10F1
AppleALC:     alc @ (DBG) comparing to 16 mod 10DE:FBA
AppleALC:     alc @ (DBG) comparing to 17 mod 10DE:FB0
AppleALC:     alc @ (DBG) comparing to 18 mod 10DE:FBB
AppleALC:     alc @ (DBG) comparing to 19 mod 10DE:FB8
AppleALC:     alc @ (DBG) comparing to 20 mod 10DE:FB9
AppleALC:     alc @ (DBG) comparing to 21 mod 10DE:10F0
AppleALC:     alc @ (DBG) comparing to 22 mod 10DE:FBC
AppleALC:     alc @ (DBG) comparing to 23 mod 1022:1457
AppleALC:     alc @ (DBG) comparing to 24 mod 1022:15E3
AppleALC:     alc @ (DBG) missing ControllerModInfo for 0 controller
AppleALC:     alc @ (DBG) missing ControllerModInfo for 1 controller
AppleALC:     alc @ (DBG) found analog codec IOHDACodecDevice
AppleALC:     alc @ (DBG) storing codec info for 10EC:295:100002
AppleALC:     alc @ failed to find IOHDACodecVendorID, retrying 0
AppleALC:     alc @ (DBG) found supported Realtek ALC295 codec revision 0x100002
AppleALC:     alc @ (DBG) missing ControllerModInfo for 0 controller
AppleALC:     alc @ (DBG) missing ControllerModInfo for 1 controller
AppleALC:     alc @ (DBG) will route resource loading callbacks
AppleALC:     alc @ (DBG) checking patch 0 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 0  for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 1 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 2 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 2  for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 3 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 3  for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 4 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 4  for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 5 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 5  for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 6 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) applying patch 6  for 9 kext (com.apple.driver.AppleHDA)
AppleALC:     alc @ (DBG) checking patch 7 for 9 kext (com.apple.driver.AppleHDA)
AppleALC:   iokit @ (DBG) getOSData layout-id has 7 value
AppleALC:     alc @ (DBG) initializePinConfig AppleHDACodecGeneric received hda 0xFFFFFF802BA87020, config 0xFFFFFF80290CDE60 config name AppleHDAHardwareConfigDriver apple layout 7 codec 10EC0295 layout 14
AppleALC:     alc @ (DBG) discovered HDAConfigDefault with 25 entries
AppleALC:     alc @ (DBG) layoutLoadCallback 4 0 1 15073 1
AppleALC:     alc @ (DBG) resource-request arrived layout
AppleALC:     alc @ (DBG) checking codec 10EC:295:100002
AppleALC:     alc @ (DBG) selecting from 8 files
AppleALC:     alc @ (DBG) comparing 0 layout 1/E
AppleALC:     alc @ (DBG) comparing 1 layout 3/E
AppleALC:     alc @ (DBG) comparing 2 layout D/E
AppleALC:     alc @ (DBG) comparing 3 layout E/E
AppleALC:     alc @ (DBG) found layout at 3 index
AppleALC:     alc @ (DBG) layoutLoadCallback done 4 0 1 1695 1
AppleALC:     alc @ (DBG) platformLoadCallback 5 0 1 14921 1
AppleALC:     alc @ (DBG) resource-request arrived platform
AppleALC:     alc @ (DBG) checking codec 10EC:295:100002
AppleALC:     alc @ (DBG) selecting from 8 files
AppleALC:     alc @ (DBG) comparing 0 layout 1/E
AppleALC:     alc @ (DBG) comparing 1 layout 3/E
AppleALC:     alc @ (DBG) comparing 2 layout D/E
AppleALC:     alc @ (DBG) comparing 3 layout E/E
AppleALC:     alc @ (DBG) found platform at 3 index
AppleALC:     alc @ (DBG) platformLoadCallback done 5 0 1 592 1
AppleALC:     alc @ (DBG) power change AppleHDADriver at AppleHDACodecGeneric from 1 to 2 in from pin 0 sleep 0

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

vit9696 commented 5 years ago

There exist similar issues in the bugtracker. Almost always they are caused by ACPI issues.

black-dragon74 commented 5 years ago

Thanks for the info Vit! I’ll do some debugging and report back.

black-dragon74 commented 5 years ago

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!

vit9696 commented 5 years ago

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.

black-dragon74 commented 5 years ago

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.

black-dragon74 commented 5 years ago

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.

Sniki commented 5 years ago

@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

vit9696 commented 5 years ago

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.

black-dragon74 commented 5 years ago

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

Sniki commented 5 years ago

@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.

Sniki commented 5 years ago

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.

black-dragon74 commented 5 years ago

@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

Sniki commented 5 years ago

@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 ?

Sniki commented 5 years ago

@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

vit9696 commented 5 years ago

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.

black-dragon74 commented 5 years ago

@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.

Sniki commented 5 years ago

@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

ghost commented 5 years ago

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.

Sniki commented 5 years ago

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.

vit9696 commented 5 years ago

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.

Sniki commented 5 years ago

@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.

Sniki commented 5 years ago

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.

  1. 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:

  2. Is it possible to implement an IRQfixes or FixIRQ Quirk to fix this problem ?

  3. 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 ?

vit9696 commented 5 years ago
  1. That's too bad to suggest.

  2. 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.

  3. 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.

Sher1ocks commented 5 years ago

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"));

https://github.com/acidanthera/AppleALC/blob/79526bc625f11e3cee6aaa379d65b2957c96a3c5/AppleALC/kern_alc.cpp#L407

i need to command verb when boot and wakeup to command verb when booting, how can i add? just add like this?

BootConfigData
                <data>
                AUcMAg==
                </data>
                <key>WakeConfigData</key>
                <data>
                AUcMAg==
                </data>
                <key>WakeVerbReinit</key>
                <true/>
Sher1ocks commented 5 years ago

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

Sniki commented 5 years ago

@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.

vit9696 commented 5 years ago

If you need it in other times than boot and wake currently it is unsupported. Otherwise just feed AppleALC with the verbs.

07151129 commented 4 years ago

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.

michyprima commented 4 years ago

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?

lvs1974 commented 4 years ago

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)

Sniki commented 4 years ago

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

michyprima commented 4 years ago

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?

lvs1974 commented 4 years ago

@michyprima, I updated attached archive in my previous post, since that version caused high cpu usage by kernel_task.

diff.patch.zip

lvs1974 commented 4 years ago

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

lvs1974 commented 4 years ago

@Shiyang-Wang confirmed that fix works.

Sniki commented 4 years ago

@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 ?

lvs1974 commented 4 years ago

@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.

xzchina commented 4 years ago

以前的版本不可靠。我尝试了很多放置延迟的地方(即使在IOHDACodecDevice :: executeVerb中也尝试了5次重试)。 唯一稳定的变量(至少在我的机器上):将AppleHDAController :: start延迟500 ms。请试一试。 AppleALC-1.4.7-DEBUG.zip diff.patch.zip

cool !!!!

Sniki commented 4 years ago

@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 !

cy2k commented 4 years ago

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?

Screen Shot 2020-06-24 at 11 52 43 PM

SheehabMuhammad commented 4 years ago

Did I do it right?

Screen Shot 2020-06-24 at 11 52 43 PM

You have "Enabled 1" not "Enable". Fix it and try again.

SheehabMuhammad commented 4 years ago

@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.

lvs1974 commented 4 years ago

@MuhammadSheehab, did you try to specify higher values for alcdelay (3000 is maximum)?

Shiyang-Wang commented 4 years ago

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.

lvs1974 commented 4 years ago

@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.

Sniki commented 4 years ago

@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

Sniki commented 4 years ago

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 !

lvs1974 commented 4 years ago

@Sniki, in my case these patches did not help. Only with a delay it works. So it is probably hardware-related bug.

Sniki commented 4 years ago

@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 !

SheehabMuhammad commented 4 years ago

@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: `/*

`