VoodooHDA 3.1.2

[schrup21]

@deeveedee I wish I hadn't overlooked your comment about the connection between AppleALC and VoodooHDA; it would have saved me my journey down the rabbit hole. 😅

I believed that using AppleALC together with VoodooHDA was causing my problem of the microphone not working, and therefore I wanted to find out the reason why VoodooHDA alone does not detect an audio device.

This topic has become quite extensive, and although I enjoy reading up on it, I obviously hadn't found the right information (from you) regarding the potential conflict between VoodooHDA and AppleGFXHDA and its solution.

I now understand that AppleALC only acts as a blocker in this scenario, and therefore its use in conjunction with VoodooHDA is perfectly suitable.

My microphone works with reactivating AppleHDA, hence my question about whether this problem can be solved.
I have a feeling VoodooHDA is detecting a wrong microphone, as it shows a "Microphone (Digital)" - but AppleHDA detects an "Internal Microphone".

 

I get output with getdump but not if voodoohda detects no audiodevice.getdump_AppleALC.txt

Edited December 22, 2025 by schrup21

[deeveedee]

@schrup21 I am not experienced with patching VoodooHDA.kext, but others in this thread are.  The fact that your Mic works with AppleALC in macOS prior to Tahoe (and when you restore AppleHDA in Tahoe) should mean that you will be able to configure VoodooHDA to properly detect and activate your Mic.  I wish I had more to offer.  Patching VoodooHDA is something I want to learn, but I haven't studied it yet.  Good luck!

 

EDIT: I know you know this, but just so that others aren't confused when reading this post, VoodooHDA.kext and AppleALC.kext can coexist in Tahoe because Tahoe does not have AppleHDA and so AppleALC does not fully load (AppleALC renames HDAS->HDEF and blocks AppleGFXHDA, but that's it).  Once AppleHDA is restored in Tahoe (using OCLP or similar patching technique), VoodooHDA and AppleALC cannot coexist in Tahoe.

Edited December 22, 2025 by deeveedee

[PG7]

@Slice

 

Hello team,

I have a question: would the VoodooHDA.kext be compatible with the internal microphone of an All-in-One?

Thanks for your answers.

Spoiler

 

codec0_dump.txt

[schrup21]

@PG7 Just give it a try, you've got nothing to lose 😉

My laptop's built-in microphone was recognized, but it didn't work. Perhaps further patches were needed...

[Slice]

Yes, some patches may be needed. Do a dump with VoodooHDA -> getdump and we will see what is wrong

[laobamac_yyds]

EDIT : Fortunately, VoodooHDA is an excellent project... My audio has been solved for the time being.

 

But there is obvious noise and sound quality loss in my ALCS1220A... Alas...

2 minutes ago, MakAsrock said:

Unfortunately, even -amfipassbeta doesn't help in my case. I immediately get a kernel panic. 🙁

Em? Strange.

You use Clover?

 

Normally saying just need shown in the figure (-lilubetaall and -amfipassbeta can be chosen, Lilu must be the latest development version)

Edited February 23 by laobamac_yyds

[MakAsrock]

3 minutes ago, laobamac_yyds said:

EDIT : Fortunately, VoodooHDA is an excellent project... My audio has been solved for the time being.

 

But there is obvious noise and sound quality loss in my ALCS1220A... Alas...

I have Realtek ALC897-I
I have similar loss of sound quality and noise. 
For me, the sound through the built-in ALC897 codec is not important, since the monitor has a speaker output.

[laobamac_yyds]

Yes... Especially when playing low volume or bass/treble audio, there is an extremely obvious noise.

I can only wait for Apple to release KDK as soon as possible, because I don't have monitor audio.

[Slice]

1 hour ago, laobamac_yyds said:

Yes... Especially when playing low volume or bass/treble audio, there is an extremely obvious noise.

I can only wait for Apple to release KDK as soon as possible, because I don't have monitor audio.

Check in VoodooHDA this line

The InputMonitor may produce a noise.

Also reduce Mixer values to 90-95. Value of 100 produces a noise.

3 hours ago, MakAsrock said:

To prevent a potential null pointer dereference.
This doesn't usually happen, but it can happen.

I am waiting to see your find.

[Allan]

9 minutes ago, Slice said:

Check in VoodooHDA this line

The InputMonitor may produce a noise.

Also reduce Mixer values to 90-95. Value of 100 produces a noise.

I am waiting to see your find.

 

A kind of post that needs to be saved! 📌

 

Thanks @Slice 

[LockDown]

7 hours ago, Slice said:

Check in VoodooHDA this line

The InputMonitor may produce a noise.

should this be checked or no?

[laobamac_yyds]

Thanks @Slice!

But there is no sound after this setting. The volume adjustment slider can be moved.

[Slice]

4 hours ago, laobamac_yyds said:

Thanks @Slice!

But there is no sound after this setting. The volume adjustment slider can be moved.

Set also iMix to 95

[laobamac_yyds]

9 hours ago, Slice said:

Set also iMix to 95

There is still no sound.

[Slice]

14 minutes ago, laobamac_yyds said:

There is still no sound.

Look also for VoodooHDA.prefPane. Yes, it works even in Tahoe!

Copy into /Library/PreferencePanes and double-click to install into System Settings.

VoodooHDA.prefPane.zip

[MaLd0n]

Very nice new things on VoodooHda. Thx to devs!!!

https://github.com/CloverHackyColor/VoodooHDA/pull/10

https://github.com/rdmitry0911/VoodooHDA/commit/408152599f3d0ae5c17c69cb9562ab7aea12908f

VoodooHDA.pkg.zip

[Max.1974]

Works good and smooth my friends!!! Aproved!!  

 

 

 

Thanks @MaLd0n for send PM to test thanks all devs!! 

 

Don't forget to change name in Device Properties 

 

[Pc Bacabal]

Work in OC too or only Clover?

[jlrycm]

1 hour ago, Pc Bacabal said:

Work in OC too or only Clover?

It should work in both OC and Clover

[Max.1974]

1 hour ago, Pc Bacabal said:

Work in OC too or only Clover?

 

46 minutes ago, jlrycm said:

It should work in both OC and Clover

 

Working good too on Opencore  

 

 

 

[deeveedee]

On 3/4/2026 at 7:23 AM, MaLd0n said:

Very nice new things on VoodooHda. Thx to devs!!!

 

Generated with Claude Code?  Very cool.  Looking forward to testing.

 

EDIT: Works very well!  Auto-sensing of internal speaker / external headset works perfectly.  Using with SIP csr-active-config = <01000000>.

 

EDIT 2: I did not need to rename / change my "layout-id" property in DeviceProperties, since VoodooHDA.kext 3.1.0 is designed to "Read alc-layout-id (preferred) or layout-id from IORegistry".  To install this new version, I did the following:

• Remove VoodooHDA.kext 3.0.3 from /Library/Extensions
• Relax SIP (csr-active-config) and reboot
• Install using VoodooHDA.pkg and reboot
• Restrict SIP (csr-active-config = <01000000>)
• Reboot and test

 

Note that on first reboot following install, Volume in the menu bar showed the wrong output (headphones) even though audio played properly through speakers.  A subsequent reboot fixed the Volume output icon.

Edited March 5 by deeveedee

[jlrycm]

3 hours ago, deeveedee said:

 

Generated with Claude Code?  Very cool.  Looking forward to testing.

 

EDIT: Works very well!  Auto-sensing of internal speaker / external headset works perfectly.  Using with SIP csr-active-config = <01000000>.

 

EDIT 2: I did not need to rename / change my "layout-id" property in DeviceProperties, since VoodooHDA.kext 3.1.0 is designed to "Read alc-layout-id (preferred) or layout-id from IORegistry".  To install this new version, I did the following:

• Remove VoodooHDA.kext 3.0.3 from /Library/Extensions
• Relax SIP (csr-active-config) and reboot
• Install using VoodooHDA.pkg and reboot
• Restrict SIP (csr-active-config = <01000000>)
• Reboot and test

 

Note that on first reboot following install, Volume in the menu bar showed the wrong output (headphones) even though audio played properly through speakers.  A subsequent reboot fixed the Volume output icon.

@deeveedee I thought I had to change csr to 03800000 to install the updated voodooHdA kext using the package that @MaLd0n shared above, but I forgot about it and tried to install it still having 01000000 and guess what? The new kext installed.

[LockDown]

3 hours ago, deeveedee said:

EDIT 2: I did not need to rename / change my "layout-id" property in DeviceProperties, since VoodooHDA.kext 3.1.0 is designed to "Read alc-layout-id (preferred) or layout-id from IORegistry".

does this mean voodoohda will have an effect base on ID like AppleALC?

Edited March 6 by LockDown

[deeveedee]

10 hours ago, jlrycm said:

@deeveedee I thought I had to change csr to 03800000 to install the updated voodooHdA kext using the package that @MaLd0n shared above, but I forgot about it and tried to install it still having 01000000 and guess what? The new kext installed.

Good observation!  That should be the case if you install the new VoodooHDA.kext if you haven't rebooted after removing the old VoodooHDA.kext from /Library/Extensions.  New installations of VoodooHDA.kext 3.1.0 will need relaxed SIP for the initial installation.

 

10 hours ago, LockDown said:

does this mean voodoohda will have an effect base on ID like AppleALC?

I'm not sure what you mean by "effect base on ID".  I got the impression that if you already have the id configured for AppleALC, you don't need to change it for VoodooHDA 3.1.0.

Edited March 6 by deeveedee

[deeveedee]

With VoodooHDA.kext 3.1.0, I no longer need to block AppleGFXHDA with AppleALC.kext as I reported here.  When using VoodooHDA.kext 3.1.0, I have AppleALC's MaxKernel = 24.99.99 (Sequoia), so that I can multiboot macOS Tahoe with older versions of macOS.  AppleALC is still used for macOS up to Sequoia and VoodooHDA is used for Tahoe.

 

EDIT: After further testing, I am finding that I still need to use AppleALC.kext as a AppleGFXHDA blocker when using VoodooHDA.kext 3.1.0 with Tahoe on my HP EliteDesk 800 G4/G5 Mini.  Note that I do not need to use AppleALC with VoodooHDA on my HP EliteBook 850 G7.

Edited March 16 by deeveedee