All Activity

@Zevgoli I don't use revpatch in boot-args (I insert revpatch in NVRAM > Add > 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102), so I don't know the boot-arg syntax, but I'm suspicious of having two revpatch= statements in boot-args. The syntax that I know is revpatch=arg1,arg2 (the revpatch arguments are comma delimited). Also, depending on which macOS you're running, I don't think that amfi_get_out_of_my_way=1 works any more. I don't think you should be using it at all (I'd prefer using AMFIPass.kext if you're using it for OCLP), but that's just my preference. If you actually need it, then you probably should be using amfi=0x80 instead. Whenever you're asking questions about your config.plist, it's best to post the entire config.plist.

You all know the hassles Ive been having updating from one version to another. I was thinking could it be a boot arg that is causing the problem? Here are the ones I am currently using: -igfxvesa revpatch=sbvmm -btlfxboardid brcmfx-country=#a revpatch=auto npci=0x2000 amfi_get_out_of_my_way=1 Are there any here that might be a red flag to anyone? Thanks for any help. Cheers, Howard

Now that HDAUniversal is working well on my HP EliteBook 850 G7 laptop with MaLd0n's updated version here, I removed boot-arg alcid and kept only DeviceProperty layout-id. HDAUniversal continues to work fine with this configuration. EDIT: The same audio DeviceProperties are working fine with AppleALC (macOS up to Sequoia), VoodooHDA 4.0 (macOS Tahoe) and HDAUniversal (macOS Tahoe).

I now have HDAUniversal working well on my HP EliteBook 850 G7 laptop in one Tahoe test Volume thanks to MaLd0n's updated kext here. I will maintain two Tahoe test volumes so that I can continue to experiment with both VoodooHDA and HDAUniversal. If either solution eventually enables Intel iGPU HDMI, that would be awesome, but for now, both solutions are outstanding. Thank you Slice and MaLd0n and any other Devs helping behind the scenes.

The problem was that the app was not always using the real hardware codec ID as the primary source. Check if work now. https://limewire.com/d/66w2b#nORvVw48bi Good to know

@MaLd0n Well done! Internal Intel HD audio is now working on my HP EliteBook 850 G7 laptop with your latest HDAUniversal!!! 🙌🙌 And you are correct, with your latest HDAUniversal.kext, HDAS is renamed to HDEF, so Codec-Info detects my audio without SSDT-HDAS. Nice work!!! ... and audio quality is outstanding! Menu Bar Codec-Info EDIT: I installed HDAUniversal with SIP csr-active-config = <03000000>. After installation, I restricted SIP with csr-active-config = <01000000>. All working well.

HDAUniversal-Release.zip Test this. Added a new personality for IOPCIClassMatch 0x04010000&0xffff0000. Remove SSDT HDAS, u dont need it, kext rename audio device. I'l check it

@MaLd0n I have an issue with codce-info, just in case you want to check in. This is Sonoma with AppleALC. No root patches. I'm sure that my onboard code is ALC1220. It's what I see in IOReg, Hackintool and ATH. But codec-info says that my codec is ALC897. Attached the logs. Maybe I am wrong and codec-info is intended to be used only with HDAUniversal. HDAUniversal-Test-Logs-2026-07-03_13-45-01.zip

@luxinhaus Only for onboard sound for now

Anyone got Intel HD630 HDMI audio working? AppleALC works with layout 11 but not with HDAUniversal. Tried all available layouts

New version 4.5.3 Fixes a bug where changing macOS version on the Firmwares tab did not reload the installers list with the same macOS Added macOS 14.0 UI fixes Version bump from to 4.5.3 (build 253) https://github.com/perez987/DownloadFullInstaller/releases/tag/4.5.3

Sonoma end of life will be sooner than for Tahoe.

I still have sonoma as well on one of my backup disk. I just don't bother to update it to Tahoe. 😅

but is AppleVTD activated? (it should, because I guess it would cause a KP otherwise) I've only added the mandatory properties according the documentation: disable-io-mapper, firmware-hash, firmware-path and srom-slide (the last would only be required for 4350 chips but doesn't hurt) you can verify if the kext is loaded with kextstat + you can grep the bcmc related log entries using dmesg (Acidanthera's debug enhancer is required for dmesg) kextstat | grep bcmc sudo dmesg | grep bcm

I suggest to use the thread but It's up to you to decide. You not need to use the EFI just open the config 5450.plist then you will see what is need for the ATI 5450 Good luck to inject ATI 5450 with OC

Thank you for the quick diagnosis! No worries - I'll switch back to VoodooHDA.kext. Note that I did try renaming HDAS to HDEF after I saw the match in HDAUniversal's Info.plist, but that was not sufficient to load HDAUniversal. EDIT: @MaLd0n I played with this a little more and was able to get HDAUniversal to load, but it was intermittent. Sometimes it would load if I changed HDAUniversal's Info.plist (changing HDEF->HDAS and/or changing PCIClass) and sometimes it would load if I renamed ACPI HDAS->HDEF and/or change class-code. I couldn't figure out why it loaded some times and not others, but even when it did load, I still did not have audio. Based on your previous explanation, I think this is expected but I wanted to let you know in case it helps you. Thanks for your hard work on this.

@schrup21 I tweaked a bit my config.plist file removing a device property line "bcmc-srom-slide" that I defined as 00000000 and added the property "bcmc-disable-io-mapper" defined as 00000000 which is what you add. The computer now arrives at the desktop but frozen, which is different from what I was experiencing, as before the computer was freezing on a black screen that shows up after the Apple logo disappears. I verified again the boot args and device properties and nothing else has been messed AFAIK. wifi.log.zip

The device is exposed by firmware as HDAS with PCI class 040100, which means generic multimedia audio/SST-cAVS style, not classic HDA 040300. HDAUniversal currently matches only HDEF or real HDA class 040300, so it never reaches start() and cannot rename the device. We need controlled HDAS/040100 support with strong HDA validation, not a blind match, to avoid attaching to the wrong audio controller.

Why don't you use the thread as reference then? Whether you use OpenCore or Clover I don't think it matters.

I would follow the link above first and make it work

I prefer not to use prebuilt EFIs; just use them as reference, and it's a Clover EFI; I would rather use OpenCore.

Thank you. I was only trying to have working Codec-Info first (which is supposed to be used when AppleALC or VoodooHDA are installed). I was able to get Codec-Info working after adding a custom _DSM for HDAS. EDIT: The attached archive has the ACPI patches and SSDT that I added to have working Codec-Info. Without this, Codec-Info did not detect my hack's audio. I don't believe that all of the properties in the SSDT are necessary, but I didn't experiment further since I was just happy that it worked. I was hoping that this fix would also work for HDAUniversal, but as MaLd0n explained (and as I observed), this is not the case. Archive.zip

@MaLd0n Without making any other changes, I ACPI-patched my hack's HDAS._DSM and now have working Codec-Info in macOS Tahoe. I'm sure that UniversalHDA will work now. Thank you for providing this great solution! EDIT: I spoke too soon. After removing VoodooHDA.kext, rebooting, installing UniversalHDA.kext and allowing it in System Settings and rebooting, I have no audio. My HDAS._DSM fixes Codec-Info in Tahoe on my hack, but not UniversalHDA. My logs are attached. 1. The zip generated by Collect-HDAUniversal.command: attached 2. Your codec model: ALC285 3. Your layout-id: 11 4. macOS version: Tahoe 26.6 (25G5052e) 5. Bootloader used: Open Core 1.0.7 6. Whether the kext is installed in /Library/Extensions: yes 7. A clear description of the problem: UniversalHDA.kext does not load 8. Steps to reproduce the issue: Install UniversalHDA with installer, allow kext in System Settings when prompted, reboot, UniversalHDA.kext is not loaded. Note that audio works without issues using AppleALC in Catalina, Sonoma and Sequoia. Audio works without issues with VoodooHDA.kext 4.0 in Tahoe. EDIT2: This might offer a clue: If I rebuild kextcache with Hackintool, kextstat shows that HDAUniversal is loaded. Still no audio, but at least the kext is loaded. kextstat | grep -i hda Executing: /usr/bin/kmutil showloaded No variant specified, falling back to release 178 0 0xffffff7f96628000 0x71c91 0x71c91 org.olarila.driver.HDAUniversal (0.1.185) 75DFF14F-0E79-3D73-9394-FC1E383FF161 <147 19 7 6 3> EDIT3: After rebooting (following rebuild of kextcache with Hackintool, HDAUniversal.kext is no longer loaded). HDAUniversal-Test-Logs-2026-07-02_18-58-24.zip

HdaUniversal is an IOAudioFamily-based kext in the sense that it is a real audio driver. It creates and publishes audio devices, engines, streams, volume controls, inputs/outputs, mixer controls, mute, jack sense, and so on. In other words, it directly participates in the `IOAudioFamily` / `IOAudioEngine` stack. HdaUniversal can use AppleALC layouts as a codec configuration source. These layouts provide codec-specific data such as layout IDs, pin configurations, path maps, node routing, input/output associations, speaker and headphone paths, microphone paths, combo-jack behavior, and other topology information. Instead of using those layouts to patch AppleHDA like AppleALC does, HdaUniversal can read and apply the same layout information inside its own driver logic. This allows HdaUniversal to configure the HDA codec, build the correct audio paths, create the proper IOAudio ports and controls, and publish the expected input/output devices directly through its own IOAudioFamily implementation. That is why, if your codec works with AppleALC, it will also work with HdaUniversal.

@deeveedee But to test HDAUniversal, you have to disable or remove any other audio kexts like VoodooHDA or AppleALC. Both kexts (HDAUniversal and VoodooHDA) don't work well together. No way to maintain VoodooHDA while testing HDAUniversal.