Contribute
Register

No audio on Dell 3471 with Realtek 3820

Please use the attached AppleALC.kext:
  • Copy to EFI/OC/Kexts folder in EFI partition of USB flash drive
  • Reboot and choose USB flash drive to boot from
  • Also check timestamps of the files inside the kext package, which should be 3:41 PM Pacific or 6:41 PM Eastern
Screenshot 2024-02-18 at 3.43.02 PM.png
 

Attachments

  • AppleALC.kext.zip
    1.4 MB · Views: 2
Last edited:
Did it. Similar outcome. :
1708298450685.jpeg
 

Attachments

  • Lilu_1.6.7_23.3.txt.zip
    313 KB · Views: 1
Checked creation date. Correct. Ran new ALC. Similar.
1708300209754.jpeg
 

Attachments

  • Lilu_1.6.7_23.3.txt.zip
    313 KB · Views: 1
I have not been clearing NVRAM, but that shouldn't be necessary. And I just installed public ALC.kext on the hard drive so if the log (future) shows casey comments the active ALC version must come from the USB drive. (I wondered whether I was failing to boot from the USB - but not so.) Will reboot again. I'll only write if something changes.
 
moshes said:
I have not been clearing NVRAM, but that shouldn't be necessary. And I just installed public ALC.kext on the hard drive so if the log (future) shows casey comments the active ALC version must come from the USB drive. (I wondered whether I was failing to boot from the USB - but not so.) Will reboot again. I'll only write if something changes.
Click to expand...
There must be a ghost in the system :) because the log contains these entries:

Code: 
AppleALC       alc: @ (DBG) casey: ADDPR(kextList)[2].user[0] is False
AppleALC       alc: @ (DBG) casey: progressState & ProcessingState::CodecsLoaded is False

But the source code has these lines commented out:
Screenshot 2024-02-18 at 4.21.05 PM.png
 
This is the kext I am using. It is on a USB drive, and the ALC on the system drive is the stock version now.
1708302439203.jpeg


I will boot yet again from the USB drive with debug boot args. Will send new log soon.
 
This has got to be right. Log created 7:42 (EST) but just like last times.
1708303467238.jpeg
 

Attachments

  • 1708303404519.jpeg
    1708303404519.jpeg
    225.2 KB · Views: 4
  • Lilu_1.6.7_23.3.txt.zip
    313 KB · Views: 1
Signing off for tonight.
 
moshes said:
This has got to be right. Log created 7:42 (EST) but just like last times.
Click to expand...
Yes this time it's correct! Log shows 3 patches applied to device 0xA2F0 instead of the original 1:

Code: 
AppleALC       alc: @ (DBG) handling 1 controller 8086:A2F0 with 3 patches - 200 Series PCH HD Audio
AppleALC       alc: @ (DBG) checking patch 0 for 2 kext (com.apple.driver.AppleHDAController)
AppleALC       alc: @ (DBG) applying patch 0 for 2 kext (com.apple.driver.AppleHDAController)
Lilu      mach: @ (DBG) getRunningPosition 0xffffff7fb298b000 of memory 94208 size
AppleALC       alc: @ (DBG) checking patch 1 for 2 kext (com.apple.driver.AppleHDAController)
AppleALC       alc: @ (DBG) applying patch 1 for 2 kext (com.apple.driver.AppleHDAController)
Lilu      mach: @ (DBG) getRunningPosition 0xffffff7fb298b000 of memory 94208 size
AppleALC       alc: @ (DBG) checking patch 2 for 2 kext (com.apple.driver.AppleHDAController)
AppleALC       alc: @ (DBG) applying patch 2 for 2 kext (com.apple.driver.AppleHDAController)

We can try enabling the delay next time with boot argument alcdelay=3000. We should use the attached AppleALC, which won't retry 400,000 times.

Good night!
 

Attachments

  • AppleALC.kext.zip
    1.4 MB · Views: 3
Last edited:
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top