VoodooHDA 3.0.2

[Slice]

8 hours ago, Bradamante said:

Well, that might be a bit of a problem since the ALC3229 aka ALC282 is HDEF@1B and the HDMI audio is HDAU@3. Using OpenCore I can use AudioDxe to output the boot chime on the internal speakers via HDEF.

So I guess I have to use AppleHDADisabler? How can I make sure that kexts are loaded in the right order (HDADisabler first, I assume)? Is the VoodooHDA edit with "IOPCIPrimaryMatch" still the way to go?

 

Should I do a DSDT patch like:

 

 

First, I don't think AudioDxe has a deal with ACPI names. 

Yuo may safely rename HDEF -> HDAS, and HDAU -> HDMI

AppleHDADisabler is still a valid way. If you are using OpenCore then load disabler before... Before what? VoodooHDA can't be loaded by Opencore. It must be in LE.

IOPCIPrimaryMatch is also a valid way.

As well as a way IONameMatch=HDAS which excluded the conflict and will not attach VoodooHDA to HDMI which is controlled by AppleGFXHDA.kext in the case of Radeon or Intel graphics.

[kocoman]

i have cs4206 applealc on montery there is sound but its high pitched and sounds like fast forwarding. any ideas thx. possible to install voodoohda on montery? thx

[Slice]

2 hours ago, kocoman said:

i have cs4206 applealc on montery there is sound but its high pitched and sounds like fast forwarding. any ideas thx. possible to install voodoohda on montery? thx

Yes, VoodooHDA works in Monterey and in Ventura too.

VoodooHDA has numerous possibilities to adjust sound quality.

[kocoman]

where is 3.0.1 dl its not on 1st thread? thx

[Bradamante]

On 4/29/2021 at 9:28 PM, Slice said:

 

 

I manage to make it working under Big Sur.

1. Set restricted enabled SIP

            <key>CsrActiveConfig</key>
            <string>0x0285</string>

2. Copy the kext into LE

sudo cp -R /path_to_kext/VoodooHDA.kext  /Library/Extensions

3. In the case of Ventura this is not enough. You should also load the kext

sudo kextutil -v /Library/Extensions/VoodooHDA.kext

 

4. The system ask you to look into System Preferences -> Security and enable here VoodooHDA

 

I just did a fresh install of Big Sur 10.16.6 on my ASUS laptop. The problem is that VoodooHDA is just not being loaded. When I do:

 

Quote

kextstat | grep -E "AppleHDA|VoodooHDA|AppleALC|Lilu"

 

I get:

 

Quote

Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
   48    7 0                  0x2e000    0x2e000    as.vit9696.Lilu (1.6.0) 6167D1C2-7FCA-3319-8246-9CAAFA704235 <8 6 5 3 2 1>
  131    0 0xffffff7f99a7f000 0x13000    0x13000    com.apple.driver.AppleHDAController (283.15) 346EC72F-571F-326B-BB68-3DA7568D9FD5 <130 129 119 14 8 7 6 5 3 1>

 

I have set CsrActiveConfig to 0x0285 and in Security settings is says: load kexts from anywhere. But when I copy the VoodooHDA kext into L/E I never get the usual message to confirm the kext in Security.

 

Have you ever tried your instructions on later Big Sur builds, like .6.6 or .7? Maybe something changed there?

 

When I do

 

Quote

sudo kextutil -v /Library/Extensions/VoodooHDA.kext

I get:

Quote

Defaulting to kernel file '/System/Library/Kernels/kernel'
Executing: /usr/bin/kmutil load --bundle-path /Library/Extensions/VoodooHDA.kext
Error Domain=KMErrorDomain Code=29 "Authenticating extension failed: Kext org.voodoo.driver.VoodooHDA v3.0.1 in executable kext bundle org.voodoo.driver.VoodooHDA at /private/var/db/KernelExtensionManagement/Staging/org.voodoo.driver.VoodooHDA.4BLfeH/VoodooHDA.kext:

Authenticating extension failed: Bad code signature" UserInfo={NSLocalizedDescription=Authenticating extension failed: Kext org.voodoo.driver.VoodooHDA v3.0.1 in executable kext bundle org.voodoo.driver.VoodooHDA at /private/var/db/KernelExtensionManagement/Staging/org.voodoo.driver.VoodooHDA.4BLfeH/VoodooHDA.kext:

Authenticating extension failed: Bad code signature}

 

Edited October 19, 2022 by Bradamante

[Slice]

I wrote this instruction when I came to BigSur 11.3. Then I confirm them in Monterey and then in Ventura.

36 minutes ago, Bradamante said:

 

Quote

Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
   48    7 0                  0x2e000    0x2e000    as.vit9696.Lilu (1.6.0) 6167D1C2-7FCA-3319-8246-9CAAFA704235 <8 6 5 3 2 1>
  131    0 0xffffff7f99a7f000 0x13000    0x13000    com.apple.driver.AppleHDAController (283.15) 346EC72F-571F-326B-BB68-3DA7568D9FD5 <130 129 119 14 8 7 6 5 3 1>

 

 

 

This is the error. There must not be com.apple.driver.AppleHDAController

[Bradamante]

OK after some more trial & error I got it now and the config is very different from what I am used to:

0) In my DSDT (not in config.plist via Rename function), rename all findings of HDEF to HDAS (four findings); confirm with IORegistryExplorer

1) csr-active-config = string: FF070000

2) With the kext tool of your choice, copy an unmodified(!) VoodooHDA.kext to L/E. Confirm in System Settings > Security

3) Reboot and enjoy

AppleHDADisabler and such is not needed. Thank you for your help @Slice

 

Actually AppleHDAController is still there

 

Quote

kextstat | grep -E "AppleHDA|VoodooHDA|AppleALC|Lilu"
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
   48    7 0                  0x2e000    0x2e000    as.vit9696.Lilu (1.6.0) 6167D1C2-7FCA-3319-8246-9CAAFA704235 <8 6 5 3 2 1>
  129    0 0xffffff7f99a7f000 0x13000    0x13000    com.apple.driver.AppleHDAController (283.15) 346EC72F-571F-326B-BB68-3DA7568D9FD5 <128 127 119 14 8 7 6 5 3 1>
  138    0 0xffffff7f9cd4b000 0x24000    0x24000    org.voodoo.driver.VoodooHDA (3.0.1) 30A8C5EB-5275-3170-9EDC-65FE58CD1D91 <127 14 8 6 5 3>

 

System Settings show: Speaker, headphones and HDMI audio. I can't test HDMI audio, but speakers and head phones work. Builtin mic works. Automatic switching to head phones doesn't work but that might also be the old plug.

Edited October 19, 2022 by Bradamante

[Slice]

Really, AppleHDAController is present in kextstat although absent in IORegistry.

About HDMI output.

VoodooHDA works with HDMI of Nvidia cards but not of AMD (attached but no sound).

After several attempts I made VoodooHDA is only for embedded sound (IONameMatch=HDAS) and so system kext AppleGFXHDA works with HDMI of RX570

It really works! I attached TV by HDMI and see movie with sound.

[Bradamante]

On 10/19/2022 at 9:58 PM, Slice said:

Really, AppleHDAController is present in kextstat although absent in IORegistry.

About HDMI output.

VoodooHDA works with HDMI of Nvidia cards but not of AMD (attached but no sound).

After several attempts I made VoodooHDA is only for embedded sound (IONameMatch=HDAS) and so system kext AppleGFXHDA works with HDMI of RX570

It really works! I attached TV by HDMI and see movie with sound.

 

With my current hackbook setup I have one problem: After any restart the default audio settings goes back to head phones, but I want the internal speakers to be the default after a reboot. Is there anyway to set this up using VoodooHDA?

[Slice]

There is a long way to make node patching so that your interested output will be in first group.

There is a short way but I am not tested it long ago.

https://sourceforge.net/projects/voodoohda/files/VoodooHdaSettingsLoader-109.zip/download

 

[Slice]

Now I am able to compile this kext with Xcode14.1 under Ventura and it works! Download it from topic.

 

 

 

[deeveedee]

I have VoodooHDA 2.9.8 successfully installed on my Dell Latitude E6410 running Big Sur and booting with Open Core 0.8.7.  My HackBookPro6,2 boots much faster with VoodooHDA.kext than with AppleALC.kext.   I don't know if I needed to perform all of these install steps, but here is what I did:

 

• Install VoodooHDA.kext in /L/E using Hackintool to perform the installation (Hackintool disables GateKeeper, sets kext file permissions and rebuilds kext cache - not sure if rebuild kext cache is necessary anymore).  When prompted Allow VoodooHDA.kext in System Preferences > Security & Privacy.
• copy VoodooHDA.kext to EFI/OC/Kexts and add VoodooHDA.kext to config.plist (Kernel > Add). I installed VoodooHDA.kext in both /L/E and OC/Kexts after reading @LockDown 's posts.  Not sure if both places is necessary.
• Rename HDEF to HDAS (OC config.plist: ACPI > Patch) so that AppleHDA does not detect audio.  I read this in one of @Slice 's posts.
• Add properties to Device HDAS with the attached SSDT. Without these additional HDAS properties, built-in laptop speaker was not detected/enabled.
  Spoiler

  

   

EDIT: In addition to built-in Speakers, Line-out was not detected without the attached SSDT-HDAS.  Without the attached SSDT-HDAS, only "Digital-out (HDMI)"  audio was available. 

 

Note that my OC config.plist partially disables SIP.

 

 

SSDT-HDAS.aml.zip

 

Edited December 8, 2022 by deeveedee

[deeveedee]

I am very pleased with VoodooHDA 2.9.8 running in Big Sur with OC 0.8.7 on my HackBookPro6,2.  I multi-boot Big Sur, Monterey and Ventura on my hack as I continue to refine and test my OC EFI.  Is there any plan to make VoodooHDA injectable by boot loader without requiring installation of VoodooHDA in /L/E?

Edited December 8, 2022 by deeveedee

[Slice]

3 hours ago, deeveedee said:

I am very pleased with VoodooHDA 2.9.8 running in Big Sur with OC 0.8.7 on my HackBookPro6,2.  I multi-boot Big Sur, Monterey and Ventura on my hack as I continue to refine and test my OC EFI.  Is there any plan to make VoodooHDA injectable by boot loader without requiring installation of VoodooHDA in /L/E?

I still don't know what prevented VoodooHDA to be loaded by a bootloader. May be because of superclass IOAudioFamily is deprecated. We should rewrite it to be dext but I don't know the theory of that.

[deeveedee]

My new High Sierra EFI for my HackBookPro6,2 is upgraded to OC 0.8.7 and I replaced AppleALC with VoodooHDA.  My hack boots and runs High Sierra perfectly.  Note that with High Sierra, I'm injecting VoodooHDA 2.9.8 with OC and not installing VoodooHDA in /L/E.

[Slice]

2 hours ago, deeveedee said:

My new High Sierra EFI for my HackBookPro6,2 is upgraded to OC 0.8.7 and I replaced AppleALC with VoodooHDA.  My hack boots and runs High Sierra perfectly.  Note that with High Sierra, I'm injecting VoodooHDA 2.9.8 with OC and not installing VoodooHDA in /L/E.

Yes, I am injecting VoodooHDA into Mojave by ordinary way from a bootloader.

New way is needed for BigSur 11.3+.

[MacKonsti]

Hi @Slice thank your for your continuing work on VoodooHDA

I am using AppleALC but would like to try VoodooHDA 3.0.2 on Monterey, so allow me a couple of quick questions:

 

a) can I use VoodooHDA 3.0.2 with OpenCore now? Or do I need to still install it on /L/E and set system permissions to allow kexts?

 

b) My Intel NUC8i7BEH has HDEF as definition of the device; should I rename it to HDAS via OpenCore DSDT patching? Or will it work as HDEF natively?

My controller is Realtek ALC235 [0x10EC0235] hopefully compatible.

 

c) The labels of the inputs/outputs as they are shown in System Preferences > Sound are they easily changeable? (just curious)

 

Many thanks!

[Slice]

21 minutes ago, MacKonsti said:

Hi @Slice thank your for your continuing work on VoodooHDA

I am using AppleALC but would like to try VoodooHDA 3.0.2 on Monterey, so allow me a couple of quick questions:

 

a) can I use VoodooHDA 3.0.2 with OpenCore now? Or do I need to still install it on /L/E and set system permissions to allow kexts?

 

b) My Intel NUC8i7BEH has HDEF as definition of the device; should I rename it to HDAS via OpenCore DSDT patching? Or will it work as HDEF natively?

My controller is Realtek ALC235 [0x10EC0235] hopefully compatible.

 

c) The labels of the inputs/outputs as they are shown in System Preferences > Sound are they easily changeable? (just curious)

 

Many thanks!

a) You may use OpenCore but it can't load VoodooHDA from EFI folder. You still needed to use /L/E/

b) AppleHDA will attach to HDEF and will conflict with VoodooHDA so why I recommend to rename HDEF -> HDAS for AppleHDA will not play.

c) Not easy. It is somewhere in Audio framework.

[MacKonsti]

Yes I will obviously stop using AppleALC and replace it with VoodooHDA

Do I need to still rename HDEF too HDAS?

Apologies, I should have stressed this point, of removing-disabling AppleALC obviously.

[Slice]

3 hours ago, MacKonsti said:

Yes I will obviously stop using AppleALC and replace it with VoodooHDA

Do I need to still rename HDEF too HDAS?

Apologies, I should have stressed this point, of removing-disabling AppleALC obviously.

Quote

b) AppleHDA will attach to HDEF and will conflict with VoodooHDA so why I recommend to rename HDEF -> HDAS for AppleHDA will not play.

 

[jalavoui]

On 4/29/2021 at 8:28 PM, Slice said:

<key>CsrActiveConfig</key>
            <string>0x0285</string>

I have flags set to 0xFFFFFFFF on big sur 11.6

As you said the trick is install to L/E and goto sys-prefs - security settings

now the 0x15de HDMI works (haven't renamed HDAU to HDMI) 

The HDEF device is handled by AppleALC (loaded by opencore)

I changed IOPCIClassMatch of VoodooHDA to IOPCIMatch 0x15de1002

 

Edited December 14, 2022 by jalavoui

[Casey_S.J.]

On AMD Ryzen hacks, both VoodooHDA and AppleALC work well to output sound, but mic and line-in do not generate any signal. We can see this in System Settings --> Sound --> Input where volume level indicator does not move. The same is true when attempting to record sound using any audio application. 

 

USB sound input works fine so this is not a deal breaker, but it does present an interesting technical challenge.

 

On Linux, both mic and line-in work properly so I've tried to learn from Linux and apply that to macOS in the following ways:

 

1. With Linux "trace point" capability we can log all verb commands issued to the codec. We can see exactly how Linux (a) discovers codec capabilities and (b) configures codec widgets 
   • VoodooHDA and AppleALC both have same capability to log all verbs 
   • Comparing verb logs between Linux and (a) VoodooHDA and (b) AppleALC, we see that codec discovery and configuration is done in more or less the same way, which means there are differences but those differences should not impact microphone and line-in functionality in any adverse way 
2. Because Linux is open-source, as are VoodooHDA and AppleALC, we can see how Linux configures the PCI bus with settings such as the following, and compare them with VoodooHDA and AppleALC:
   • PCI Traffic Class 
   • MSI Interrupts
   • DMA Buffer Setup
   • PCI Snoop Setting
   • Cache Inhibit
   • etc.

 

VoodooHDA already provides options to configure some of these settings. I've also attempted similar changes to AppleALC.

 

Because codec configuration "seems" to be fine, perhaps the problem lies with controller configuration (i.e. PCI bus configuration). Of course, the problem may lie somewhere else.

 

Any thoughts, comments or suggestions regarding the problem of Mic and Line-In are most welcome.

Edited December 24, 2022 by Casey_S.J.

[Slice]

In the 99% cases there is enough to change nodes configs for VoodooHDA calculates good sound pathes.

Give me getdump output I will look.

And Yes, for AMD CPU you should set InhibitCache=YES. This is one of root difference between VoodooHDA and AppleHDA.

Second difference is that VoodooHDA can distrub HDA specification for external microphone will work. AppleHDA will not.

Third difference is joining outputs into 5.1 sound. 

[Casey_S.J.]

9 hours ago, Slice said:

In the 99% cases there is enough to change nodes configs for VoodooHDA calculates good sound pathes.

Give me getdump output I will look.

And Yes, for AMD CPU you should set InhibitCache=YES. This is one of root difference between VoodooHDA and AppleHDA.

Second difference is that VoodooHDA can distrub HDA specification for external microphone will work. AppleHDA will not.

Third difference is joining outputs into 5.1 sound. 

 

@Slice

 

I've been working on this problem for a handful of weeks and have collected various logs, all of which are in the attached ZIP:

• Linux Codec Dump with Coefficients.txt
  • Raw Linux codec dump with processing coefficients 
• VoodooHDA-Dump-Gigabyte-B550-Vision-D.txt
  • Detailed trace log from VoodooHDA that contains comprehensive details 
• AppleALC Detail Logs.txt
  • Detailed logs from AppleALC -- shows all verbs issued to the codec
• Linux alsa-trace Verbs Issued to Codec.txt
  • All verbs issued to codec by Linux
• Linux alsa-trace Verbs - Annotated.rtf
  • Same as above, but with comments added by me
• linux-coefficient-dump.txt
  • Linux list of processing coefficients
• mac-coefficient-dump.txt
  • Mac list of processing coefficients (from AppleALC)

I also looked at Linux source code to see what patches it applies to AMD audio controllers. A brief summary of that is posted here:

https://forum.amd-osx.com/threads/ryzen-7000-testing.3318/page-89#post-26209

 

AppleALC is a layer on top of existing AppleHDA, which means many of the low-level chip and PCI bus I/O operations are performed by AppleHDA, and we have no source code for that.

 

But VoodooHDA is different. It does not rely upon AppleHDA and implements low-level chip and PCI bus I/O operations by itself. The entire source code is available, which makes VoodooHDA the ideal place for this type of experimentation. 

 

All of the log files are from a Gigabyte B550 Vision D (AM4 platform). This motherboard has:

 

• Inputs:
  • Rear Mic 
  • Rear Line-In
  • Front Mic
• Outputs:
  • Rear Line Out (green)
  • Rear Line Out (center channel)
  • Rear Line Out (surround)
  • Rear Optical Digital Output 

 

Mic and Line-In Investigation.zip

 

Edited December 25, 2022 by Casey_S.J.

[Slice]

See VoodooHDA.kext/Contents/Info.plist

Attention to

AllowMSI. Usually we set YES, but I am not sure about AMD CPU. Set it to NO.

Boost. It influences on sound volume. 0 - low volume, 1 - normal.

DisableInputMonitor. Set it to YES if you don't want Output to pass to Input (karaoke).

InhibitCache. It is useful for AMD CPU.

MixerValues. See my screen.

Vectorize. It is using SSE2 instruction. I think it is fine for your CPU.

 

Install VoodooHDA.prefPane to see several adjusters.