Jump to content

HDAUniversal - AppleHDA-like Audio Kext for macOS Tahoe and Hackintosh Systems


73 posts in this topic

Recommended Posts

@deeveedee 

Of course, I got your joke. OCLP was designed to let macOS run on older Macs, not Hackintoshes.

That said, I've actually been wanting to add support for HeliPort and itlwm.kext to Wi-Fi Patcher Pro for quite a while.

As for eliminating the need for OCLP... isn't that exactly what @Mald0n and I are doing? 😄

  • Like 4
  • Haha 2

@Mirone Yes - my joke was specifically about adding UniversalHDA to OCLP. Sorry I guided us OT. 

  • Like 4
5 hours ago, Slice said:

SIP is system protection against hackintosh.

... many of us are still running macOS Sequoia on our hacks with SIP fully enabled.

 

Thanks to projects like VoodooHDA.kext and UniversalHDA.kext, we can still run macOS Tahoe on our hacks with SIP still essentially enabled (only setting csr-active-config = <01000000> to allow untrusted kexts in /Library/Extensions).

Edited by deeveedee
  • Like 4

My HP EliteBook 850 G7 with CODEC ALC 285 is currently using VoodooHDA.kext 4.0 for perfectly working Intel HD audio in macOS Tahoe.

 

Spoiler

Screenshot2026-07-02at10_29_15AM.png.87e7e0d827fa8c34b60f943f99b1466c.png

 

When I run @MaLd0n's CodecInfo in Tahoe, it doesn't find audio:

Spoiler

Screenshot2026-07-02at10_26_42AM.png.91e1df25b7ac8ee5f42aaf8e1210bb3e.png

 

I suspect this means that UniversalHDA won't find my audio either.  The corresponding Codec-Info-Report is attached.  

 

What am I missing?  Is it possible to diagnose this before I attempt to install UniversalHDA.kext (since VoodooHDA.kext is working well for me)?

 

EDIT: When I run Codec-Info in macOS Sonoma, it does detect my audio:

Spoiler

Screenshot2026-07-02at10_36_56AM.thumb.png.bc8c0d9ef0974f11f33fbb0150fea7a8.png

 

The Codec-Info-Report when running Sonoma is also attached.

 

EDIT: Here's my HDAS IOReg screenshot for macOS Tahoe
 

Spoiler

HDAS-IOReg-Tahoe.thumb.png.f1fe4e773330ff8f41bdbef09d235afb.png

 

Codec-Info-Report.txt Sonoma-Codec-Info-Report.txt

Edited by deeveedee
  • Like 4

There were no issues with the import or anything else. So, the problem must be on your end. Use the `alcid=xx` parameter for AppleALC, and HDAUniversal will work. You can also attach a log; read the first post.

  • Like 2
  • Thanks 1

I'm sure the problem is on my end.  I've tried with boot-arg alcid=11, DeviceProperty layout-id=11, but neither allows Codec-Info to detect my audio in Tahoe.  I was hoping that your audio detection mechanism for Codec-Info was the same as UniversalHDA, so that I didn't have to uninstall VoodooHDA to test UniversalHDA.  I will definitely test UniversalHDA. For now, VoodooHDA 4.0 works perfectly.

  • Like 2

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

  • Like 2
  • Thanks 1

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.

  • Like 2
  • Thanks 1

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

 

Spoiler

Screenshot2026-07-02at6_21_57PM.png.45c2247e94c86c5f6581d570a4979b14.png

 

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

Edited by deeveedee
  • Like 2
1 hour ago, miliuco said:

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

 

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

Edited by deeveedee
  • Like 2

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.

  • Like 2
  • Thanks 1

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.

Edited by deeveedee

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

 

Spoiler

IOReg.thumb.png.0c89cc12780ee95a5f41679516c2f45e.png

 

Spoiler

Hackintool.thumb.png.e83d279cb8feb3ae3123ab6677d1b2c1.png

 

Spoiler

ATH.thumb.png.656bf268b55eafdfe1b0103fab24c31d.png

 

But codec-info says that my codec is ALC897.

Attached the logs.

 

Spoiler

codec-info.thumb.png.1a4b45a933ead533576167014d555340.png

 

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

Edited by miliuco
Typo
  • Like 2
11 hours ago, deeveedee said:

Thank you for the quick diagnosis!  No worries - I'll switch back to VoodooHDA.kext.

HDAUniversal-Release.zip

Test this. Added a new personality for IOPCIClassMatch 0x04010000&0xffff0000.

Remove SSDT HDAS, u dont need it, kext rename audio device.

2 hours ago, miliuco said:

@MaLd0nI'm sure that my onboard code is ALC1220. It's what I see in IOReg, Hackintool and ATH.

I'l check it

  • Like 3
  • Thanks 1

 

 

@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

Spoiler

Screenshot2026-07-03at10_03_51AM.png.10ee93a86797d1db019942a4d31c6375.png

 

 

Codec-Info

Spoiler

Screenshot2026-07-03at10_03_37AM.png.e39b1188ba59f60e79809ce4ae83c13f.png

 

 

EDIT: I installed HDAUniversal with SIP csr-active-config = <03000000>.  After installation, I restricted SIP with csr-active-config = <01000000>.  All working well.

Edited by deeveedee
  • Like 3
2 hours ago, miliuco said:

But codec-info says that my codec is ALC897.

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

16 minutes ago, deeveedee said:

@MaLd0n Well done!  Internal Intel HD audio is now working on my HP EliteBook 850 G7 laptop with your latest HDAUniversal!!! 🙌🙌

Good to know ;) 

  • Like 2

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

 

EDIT2: Interesting... HDAUniversal does not appear in Hackintool's Extensions list.  I never thought about it, but I guess Hackintool displays only Extensions that it knows.

Spoiler

Screenshot2026-07-03at12_09_25PM.png.10c7cf3228bb0d5d6aaf3aa6da179013.png

 

Edited by deeveedee
  • Like 1

I installed HDAUniversal on an HP EliteDesk 800 G4 Mini that I'm using for a multimedia system.  The EliteDesk 800 G4 Mini has two audio outputs that I'm using to drive 1) main speakers and 2) a subwoofer.  HDAUniversal is working perfectly with the Multi-Output Device that I created using macOS Tahoe's Audio MIDI Setup.  Sound quality is outstanding. 🎶

×
×
  • Create New...