VoodooHDA 3.1.2

[Slice]

On 10/9/2025 at 7:40 AM, verdazil said:

You are wrong because "prevents VoodooHDA to tune it properly" just points out the problems and shortcomings of the VoodooHDA driver. Also, this does not mean in any way that AudioDxe is somehow dependent on VoodooHDA.

Anyway this is the known problem.

[BuXb]

On 10/4/2025 at 11:10 PM, Max.1974 said:

Hi @BuXb With VoodooHDA, there’s no need to remove it — just reinstall the patch if it’s not recognized, but it usually doesn’t lose functionality. If necessary, simply run the installation script again.

yep, confirmed: today finally ran the incremental 2.8 GB 26.0.1 update with VoodooHDA present in Tahoe /L/E - ran through silky-smoothly. Afterwards I had to indeed run the script again because for the update, I had to boot with SIP enabled which rendered VoodooHDA inactive as explained here before. Happy 😎

[Max.1974]

3 horas atrás, BuXb disse:

sim, confirmado: hoje finalmente rou a atualização incremental de 2,8 GB 26.0.1 com VoodooHDA presente em Tahoe /L/E - passou suavemente. Depois, eu realmente tive que executar o script novamente porque, para a atualização, tive que inicializar com o SIP ativado, o que tornou o VoodooHDA inativo, como explicado aqui antes. Feliz 😎

 

@BuXb Happiness is not enough for someone who can surf in Hawaii, right brother? Aloha!! Woohoo! Yabadaba doo!  

[deeveedee]

5 hours ago, BuXb said:

yep, confirmed: today finally ran the incremental 2.8 GB 26.0.1 update with VoodooHDA present in Tahoe /L/E - ran through silky-smoothly. Afterwards I had to indeed run the script again because for the update, I had to boot with SIP enabled which rendered VoodooHDA inactive as explained here before. Happy 😎

Why did you need to change SIP for the update?  I leave SIP configured as csr-active-config = <01000000> after installing VoodooHDA.kext (installed with csr-active-config = <03080000>) and never touch it again.  Is it possible that you could find a SIP configuration that doesn't need to be change for macOS updates?

 

EDIT: Maybe the table here will help?

Edited October 14, 2025 by deeveedee

[BuXb]

@Max.1974 🏄‍♂️🤙

 

@deeveedee <00000000> was recommended by many people before in other threads for both, incremental updates and full (legacy bootable) backups of all recent versions of macOS to work with tools like Carbon Copy Cloner and SuperDuper!, so I've been using that successfully for a long time (in a separate dedicated ESP set as default in BIOS so it gets loaded w/o any intervention during updates). Two other dedicated ESPs (one with OC and one with Clover) with the csr value for my everyday usage I access manually via BIOS boot menu (ESC key). That's been working fine for me for ages.

 

If you confirm that Tahoe's 26.0.0 -> 0.1 incremental update indeed worked for you with <01000000>, I'll gladly test that with the upcoming 26.1 update. Before that I'll also test if CCC and SD! still work 100% with <01000000> 😎

 

(yes thanks, I've seen your most insightful SIP chart  before)

Edited October 14, 2025 by BuXb

[deeveedee]

@BuXb I have not touched VoodooHDA or SIP since I installed VoodooHDA in Tahoe 26.0 Beta 2. csr-active-config=<01000000> works, as well as some other less restrictive SIP settings (including <03080000>) in the table I posted. Completely disabling SIP (<FF0F0000>) breaks updates.

[LockDown]

I would love to use VoodooHDA in Tahoe if only supports iGPU HDMI audio

[BuXb]

@deeveedee for compatibility with several apps (incl. XtraFinder) across several versions of macOS I use <850A0000> which also breaks macOS incremental updates + full (bootable) system backups, therefore the additional ESP

Edited October 14, 2025 by BuXb

[deeveedee]

@BuXb Great. Change csr-active-config to <03080000> or <01000000> to perform the update and then back to your required setting. This way you don't need to reinstall VoodooHDA.

[Max.1974]

1 hour ago, BuXb said:

@deeveedee for compatibility with several apps (incl. XtraFinder) across several versions of macOS I use <850A0000> which also breaks macOS incremental updates + full (bootable) system backups, therefore the additional ESP

 

Optional you can use 0x803 works fine to me Lenovo T14 

 

 

 

If you will use Clover  

[deeveedee]

19 minutes ago, Max.1974 said:

 

Optional you can use 0x803 works fine to me Lenovo T14 

 

If you will use Clover  

Open Core's <03080000> is the same as Clover's 0x803.  Open Core config.plist specifies CsrActiveConfig as little endian.

[deeveedee]

On 10/9/2025 at 1:35 AM, Slice said:

It looks like old Xcode bug.

Does this justify VoodooHDA.kext 3.0.3?

[Max.1974]

23 hours ago, deeveedee said:

Open Core's <03080000> is the same as Clover's 0x803.  Open Core config.plist specifies CsrActiveConfig as little endian.

Yes, my dear, just to reinforce in case he’s going to use Clover.  

[Slice]

On 10/15/2025 at 9:47 PM, deeveedee said:

Does this justify VoodooHDA.kext 3.0.3?

Yes, tested.

I also have working VoodooHDA.prefPane

To do this the prefPane must be located in /Library/PreferencePanes/

[deeveedee]

Thank you, @Slice.  VoodooHDA.kext 3.0.3 is now available here.

 

EDIT: I'm already seeing improvements with the upgrade from 3.0.2 -> 3.0.3.  With 3.0.2, I would receive "double" feedback in macOS Tahoe when changing volume.  With 3.0.3, feedback when changing volume is normal (single feedback).

 

EDIT2: I forgot to change SIP csr-active-config from <01000000> to <03080000> before upgrading VoodooHDA.kext from 3.0.2 -> 3.0.3.  The upgrade completed anyway (with csr-active-config = <01000000>).  To perform the upgrade, I deleted VoodooHDA.kext from /Library/Extensions and then copied VoodooHDA.kext 3.0.3 to /Library/Extensions (using 'cp -R VoodooHDA.kext').  macOS prompted me to update security in System Settings and then I rebooted.  All without changing SIP.  I'm running Tahoe 26.1 Beta 4.

Edited October 22, 2025 by deeveedee

[Slice]

15 hours ago, deeveedee said:

Thank you, @Slice.  VoodooHDA.kext 3.0.3 is now available here.

 

EDIT: I'm already seeing improvements with the upgrade from 3.0.2 -> 3.0.3.  With 3.0.2, I would receive "double" feedback in macOS Tahoe when changing volume.  With 3.0.3, feedback when changing volume is normal (single feedback).

 

EDIT2: I forgot to change SIP csr-active-config from <01000000> to <03080000> before upgrading VoodooHDA.kext from 3.0.2 -> 3.0.3.  The upgrade completed anyway (with csr-active-config = <01000000>).  To perform the upgrade, I deleted VoodooHDA.kext from /Library/Extensions and then copied VoodooHDA.kext 3.0.3 to /Library/Extensions (using 'cp -R VoodooHDA.kext').  macOS prompted me to update security in System Settings and then I rebooted.  All without changing SIP.  I'm running Tahoe 26.1 Beta 4.

Yes, <01000000> is enough for third-party kexts like VoodooHDA. Other bits set as a precaution or for other hackintosh needs.

I see no sense in SIP enabled. I keep it to be maximum disabled.

System Integrity Protection. What is the Integrity if there is Hackintosh with >10 kexts and numerous patches?!

[jlrycm]

1 hour ago, Slice said:

Yes, <01000000> is enough for third-party kexts like VoodooHDA. Other bits set as a precaution or for other hackintosh needs.

I see no sense in SIP enabled. I keep it to be maximum disabled.

System Integrity Protection. What is the Integrity if there is Hackintosh with >10 kexts and numerous patches?!

I guess some users are ok with the kexts and patches since they are legit, developed by trustable individuals willing to help others and necessary to load macOS, but don’t want their systems to be more exposed and vulnerable to other stuff that is out there and considered to be malicious.

[deeveedee]

4 hours ago, Slice said:

Yes, <01000000> is enough for third-party kexts like VoodooHDA. Other bits set as a precaution or for other hackintosh needs.

I see no sense in SIP enabled. I keep it to be maximum disabled.

System Integrity Protection. What is the Integrity if there is Hackintosh with >10 kexts and numerous patches?!

<01000000> is enough for third-party kexts that have already been installed.  SIP restrictions must be relaxed (e.g., csr-active-config = <03080000>) in order to install new, unknown kexts.

 

Restricting SIP is a preference.  I won't mind that you prefer to disable SIP if you don't mind that I prefer to keep SIP as restrictive as possible.

[Max.1974]

@Slice  Thank you for version 3.0.3, I compiled it in Xcode 16.4 with Tahoe 26.0.1 on my i3-9100F ASUS Desktop with an RX 64 Vega, and the sound works perfectly. ALC887 Layout 2.  

 

And I used chris1111’s package to install it. Wonderful. 

 

 

 

 

 

 

 

Csr-Active-Config 0xA85 

[deeveedee]

EDIT: This appears to have been related to the external display, but I'm not sure why.  After connecting an external HDMI display and then disconnecting the display, Audio Output now remains "Speaker" instead of "Headphones".  I am using Tahoe 26.1 RC, so maybe this is a Tahoe issue.

 

EDIT2: This issue has not returned after I connected and then disconnected the external HDMI display.  I don't know why this would be the case.  Maybe when I was testing frame buffer patching for the external HDMI (which required lots of experimentation), I left the HDMI audio in a weird state that interfered with Audio output detection.

 

---------------------------------------------

 

Sorry if this is a remedial question or one that has been asked before ... I'm using VoodooHDA.kext 3.0.3 (Slice's build) on an HP laptop with SMBIOS MBP16,2.  Audio always selects Output: Headphones each time I boot macOS, regardless of what the audio setting was at last shutdown.  I don't have any headphones connected to the headphones port and no external display is connected.

 

Is this a known issue with VoodooHDA.kext?  The easy work-around is to select the audio output with each new macOS session, but if there's an easy way to make the output selection "sticky' that would be helpful.

 

My configuration is as follows:

• VoodooHDA.kext 3.0.3 installed in /Library/Extensions
• SIP: after installation, have tested csr-active-config values <FF0F0000> and <01000000> with no change in behavior

Thank you.

 

EDIT: Note that I have not installed the VoodooHDA prefpane

Edited November 3, 2025 by deeveedee

[deeveedee]

@verdazil I edited my previous post with the "fix" - not sure why it worked.

[LockDown]

@Slice DisableCrossAssociations exist is clover? ChatGPT says it disable HDMI in VoodooHDA

Edited November 3, 2025 by LockDown

[deeveedee]

EDIT: Removing MaxKernel 24.99.99 from AppleALC.kext appears to resolve this issue.  AppleALC.kext and VoodooHDA.kext can coexist in Tahoe, because Tahoe does not have AppleHDA.  Will test further and report back if any changes.  

 

----------------------

 

VoodooHDA.kext 3.0.3 continues to work very will with macOS Tahoe on my HackBookPro16,2.  I'm using AppleALC.kext 1.9.5 with MaxKernel 24.99.99 for earlier versions of macOS.  I have noticed that when I switch from an earlier version of macOS that uses AppleALC.kext to macOS Tahoe 26.1 RC which uses VoodooHDA.kext, that I must reboot Tahoe to restore working audio.  When I first boot Tahoe 26.1 RC with VoodooHDA after booting an earlier version of macOS with AppleALC, audio is not available.

 

Not a big deal, just reporting in case it helps someone else.

Edited November 3, 2025 by deeveedee

[schrup21]

2 hours ago, deeveedee said:

AppleALC.kext and VoodooHDA.kext can coexist in Tahoe

That's how I do it too!

Without AppleALC, VoodooHDA doesn't recognize any audio device for me - but it works perfectly with AppleALC.

[deeveedee]

@schrup21 Using AppleALC as an AppleGFXHDA "blocker" with VoodooHDA is part of my installation instructions here.  I didn't think I needed AppleALC with VoodooHDA on my HackBookPro16,2, but apparently I do.  I should have just followed my original instructions.