Navi 10 HDMI Audio Not Working

[Fortitude]

I have an Alienware Area-51m R2 laptop with a 5700M. The dGPU is connected to my internal display as well as the DP/HDMI outputs. The DisplayPort output has working audio, and I can use a DP-to-HDMI adapter to get HDMI audio working. However, I can’t get audio directly over the HDMI output. The HDMI output shows up as an available audio device when a cable is connected, but no sound comes out of my external monitor when selected.

 

Worst case, I’ll just stick with the adapter, but I feel like this should be solvable. I have a 6950 XT eGPU (Navi 21) with working HDMI audio, and unless I’m mistaken, that card doesn’t use an LSPCON chip to convert the signal from DisplayPort. Both cards use the same AMDRadeonX6000Framebuffer.kext and AppleGFXHDA.kext.

 

Is there anyone here with natively working Navi 10 HDMI audio? For reference, HDMI audio works fine on the 5700M in operating systems outside of macOS.

Edited April 8 by Fortitude

[Max.1974]

Hello, I get HDMI working on my graphics card in any situation using NootRX + VoodooHDA.kext, or WEG + VoodooHDA.kext, both with signature.

 

I even created an app now to make compiling the VoodooHDA kext easier.

 

 

To sign Kext

 

sudo codesign --force --deep --sign - /Library/Extensions/VoodooHDA.kext
 

To verify 

 

codesign -dv --verbose=4 /Library/Extensions/VoodooHDA.kext

 

 

 

 

 

 

 

I use on my Desktop with RX 6900 XT 

 

[Fortitude]

Hi @Max.1974,

Your program installs VoodooHDA perfectly, but AppleGFXHDA blocks it from attaching to the dGPU.

Do you have any suggestions?

[deeveedee]

@Fortitude Use AppleALC.kext as an AppleGFXHDA blocker.  Inject AppleALC.kext using your boot loader.

 

EDIT: Use of AppleALC as an AppleGFXHDA blocker in Tahoe assumes that AppleHDA is not patched in Tahoe.  See here to read more about the use of AppleALC as an AppleGFXHDA blocker.

Edited April 8 by deeveedee

[Fortitude]

@deeveedee Thanks for the suggestion. I tried it, including reverting root patches and patching only wireless, but it doesn't seem to work for me. That said, I’m using AppleHDA with my Realtek codec, so using AppleALC as an AppleGFXHDA blocker isn’t relevant to my setup.

 

I’m wondering if there’s a way to spoof Navi 10 audio as Navi 21 audio via a binary patch, or maybe there’s a connector flag in the framebuffer that I’m overlooking.

Edited April 8 by Fortitude

[deeveedee]

@Fortitude Your test results suggest that AppleALC does not block AppleGFXHDA on the dGPU's HDAU (which I hadn't tested).  I'm sorry that I don't have other suggestions.

[Max.1974]

6 hours ago, Fortitude said:

Hi @Max.1974,

Your program installs VoodooHDA perfectly, but AppleGFXHDA blocks it from attaching to the dGPU.

Do you have any suggestions?

 

I used this method too to fix audio, it's amazing for all Hacks !! 

 

Its made by @Hnanoto

 

https://github.com/hnanoto/SSDT-Audio-Universal 

 

 

See video tutorial in English 

 

 

 

 

 

This is mine 

 

[Max.1974]

@Fortitude Thanks for tested VoodooHDA Builder  

[Fortitude]

@Max.1974 these SSDTs appear to only influence AppleALC layout-id selection. When you check IOReg, does VoodooHDA attach to your 6900 XT? For me, VoodooHDA attaches to the Realtek codec when AppleALC is disabled, but AppleGFXHDA still attaches to my 6950 XT regardless. AppleGFXHDA enables natively working HDMI audio on my 6950 XT eGPU, which is Navi 21, but not on my Navi 10 5700M dGPU.

Edited April 8 by Fortitude

[Max.1974]

5 minutes ago, Fortitude said:

@Max.1974 these SSDTs appear to only influence AppleALC layout-id selection. When you check IOReg, does VoodooHDA attach to your 6900 XT? For me, VoodooHDA attaches to the Realtek codec when AppleALC is disabled, but AppleGFXHDA still attaches to my 6950 XT regardless. AppleGFXHDA enables natively working HDMI audio on my 6950 XT eGPU, which is Navi 21, but not on my Navi 10 5700M dGPU.

 

I have many logs, and the audio works, but I believe this is the closest to what you would need to analyze. Does this entry appear, as shown in the screenshot?

 

 

For Tahoe AppleALC is not supported anymore 

 

 

[Max.1974]

Another thing you can try to do is create a bridge (a BRG0 bridge) for your video card so that IOREG may read it better. You can use Hackintool to do this, and if you don’t know how, I can send you a tutorial from the channel here as well.

 

 

Edited April 8 by Max.1974

[Max.1974]

This is video for members of channel 

 

 

 

Try use SSDTTime to create your PCI Bridge 

 

[Fortitude]

Thanks for sharing your IOReg; yours looks similar to mine. I’ve already created a BRG0 SSDT, but it doesn’t seem to affect HDMI audio. Here’s my IOReg for reference. You’ll see that VoodooHDA attaches to my laptop’s speakers/headphones and mic/line-in, while AppleGFXHDA attaches to my 5700M (AB38) and 6950 XT (AB28). Unless anyone has HDMI audio working natively on a 5000 series card without going through an LSPCON chip, this might be uncharted territory.

 

 

 

[Max.1974]

Are you create SSDT for Audio HDEF or HDAS?

 

Its important, my HDMI audio not works without it  

 

 

Your Dump is different 

 

Edited April 9 by Max.1974

[deeveedee]

@Max.1974 I think there's some confusion here (maybe it's my confusion).  It appears to me that Fortitude is talking about HDMI audio.  It looks like the HDAS audio patches that you posted are for internal speaker/headphone audio (not HDMI audio).  

 

Is is possible to fix HDMI audio by creating patches for HDEF and HDAS?

 

EDIT: On my hack with AMD dGPU, DP/HDMI audio appears as Device HDAU (a separate device that is different from Device HDEF):

Edited April 9 by deeveedee

[MaLd0n]

Try with VoodooHDA 3.3.4 VoodooHDA.pkg.zip

[deeveedee]

Sorry for the off-topic post... MaLd0n's VoodooHDA.kext 3.3.4 recognizes audio on Device HDAU (Audio over DP) for my Radeon RX 560x.  Very cool!

 

IORegistry

Spoiler

 

Volume Control

Spoiler

 

[MaLd0n]

Follow here https://github.com/rdmitry0911/VoodooHDA

[Max.1974]

3 horas atrás, deeveedee disse:

@Max.1974Acho que há alguma confusão aqui (talvez seja a minha confusão). Parece-me que o Fortitude está falando sobre áudio HDMI. Parece que os patches de áudio HDAS que você postou são para áudio interno de alto-falante/fone de ouvido (não áudio HDMI).

 

É possível corrigir o áudio HDMI criando patches para HDEF e HDAS?

 

EDITAR: No meu hack com AMD dGPU, o áudio DP/HDMI aparece como Device HDAU (um dispositivo separado que é diferente do Device HDEF):

 

Yes, it does help with recognition. I also installed the one from MaLd0n and it recognizes it as well, but it causes distortion. It’s an excellent contribution from a parallel developer on GitHub, however I still prefer compiling it myself, where everything works exactly as it should. 

What matters is that it works. If it works well for you, use it without fear.  

But one detail: it recognizes HDMI less. For me, the parallel version didn’t recognize HDMI 100%, because the volume couldn’t be adjusted — it stayed at a single fixed volume. Only on HDMI.

With the compiled version it also recognizes it through the DP port in the same way. 

[deeveedee]

@Max.1974 Thank you for the reply.  I'm going to ask about this in the VoodooHDA.kext thread, since I don't understand why that would be the case and I don't want to go off-topic here.

[Max.1974]

9 minutes ago, deeveedee said:

@Max.1974 Thank you for the reply.  I'm going to ask about this in the VoodooHDA.kext thread, since I don't understand why that would be the case and I don't want to go off-topic here.

 

You are welcome....always  

 

I just wanted to reinforce that all efforts are valid. Even though I insist on saying that I prefer compiling with Xcode — which, in my opinion, is the key piece — because each AppleALC device is placed in the kext as a predefined library, and VoodooHDA can only achieve something similar, in a certain way, by compiling it on your own hardware.

This small detail makes all the difference. Although VoodooHDA also contains a large library, the project is different from AppleALC, which depends on other kexts such as AppleHDA, while VoodooHDA does not depend on it. This, combined with the fact that an SSDT guides the hardware (such as the BUS ID), helps avoid distortions. 

[deeveedee]

6 minutes ago, Max.1974 said:

I just wanted to reinforce that all efforts are valid.

 

Clearly you have not seen some of my efforts.    Just look at some of my old and new posts and you'll see that not all efforts are valid. 😄

[Max.1974]

1 minuto atrás, deeveedee disse:

 

Claramente você não viu alguns dos meus esforços. Basta olhar para alguns dos meus posts antigos e novos e você verá que nem todos os esforços são válidos.😄

 

A question I asked our good old AI says this about compiling or not, and the reason why VoodooHDA sometimes works better, which is why I chose to use it: 

 

In Hackintosh systems, internal audio (HDEF/HDAS) and GPU digital audio (HDAU – HDMI/DisplayPort) belong to the same macOS HDA subsystem. 

Although they are different devices, proper initialization of the main audio controller (HDEF) helps macOS build a correct device tree in the IORegistry.

When ACPI patches fix HDEF/HDAS — for example by renaming HDAS to HDEF, injecting properties like layout-id, or correcting _ADR and the device path — the macOS audio subsystem initializes more consistently. 

This allows the system to properly attach the GPU’s HDAU device responsible for HDMI/DP audio.

Additionally, an SSDT can help by:

• correcting the BUS ID

• properly exposing the HDAU device

• fixing the _ADR address

• aligning the ACPI topology between the GPU and the audio controller

 

When this topology becomes consistent, macOS can correctly associate the GPU framebuffer with the HDMI audio engine, avoiding detection failures and sometimes even reducing distortions.

 

Regarding drivers:

 

AppleALC is not a full audio driver. It works as a patch layer for the native AppleHDA driver, injecting layouts and codec configurations. 

Because it depends on proper AppleHDA initialization and a correct ACPI implementation, any inconsistency may prevent HDMI audio from appearing.

 

VoodooHDA, on the other hand, is a full standalone audio driver that does not depend on AppleHDA. 

It directly implements the HDA controller and scans the bus to detect codecs and audio devices. 

For that reason it can sometimes detect HDMI audio in configurations where AppleALC fails.

 

About compiling the kext locally:

 

Compiling VoodooHDA using Xcode on the local machine can bring indirect advantages such as:

• using the correct macOS SDK

• updated build flags

• a toolchain compatible with the current system

• the correct binary architecture

 

This does not mean Xcode “reads” the hardware directly, but it ensures the binary is built in an environment fully compatible with the running system.

 

 

[Fortitude]

You guys are seriously the best!

I finally got VoodooHDA loaded and it's working perfectly 😊

It looks like all @MaLd0n did was set the probe score super high in the info.plist.

So I used the installer that @Max.1974 made, and targeted the Navi 10 dGPU by adding the following:

			<key>IOPCIPrimaryMatch</key>
			<string>0xAB381002</string>
			<key>IOProbeScore</key>
			<integer>100000</integer>

If we now check IOReg, my Realtek audio attaches to AppleHDA, Navi 10 attaches to VoodooHDA, and Navi 21 attaches to AppleGFXHDA.

It would obviously be preferable if Navi 10 HDMI audio just worked out of the box with AppleGFXHDA, but this is good enough.

Perhaps there's a way to binary patch AppleGFXHDA or AMDRadeonX6000Framebuffer to work properly with HDMI audio, but I'm not sure if it's possible.

 

 

My last question is if it's possible to rename the outputs to something other than Digital-out, or hide them when an external monitor is disconnected?

Otherwise, I'm really glad I reached out to you all. This has been driving me crazy for a long time.

[Max.1974]

Congrats @Fortitude !! That is it !! 😄 

 

Enjoy it  

What version VoodooHDA are you using ? 

 

 

Use this to check: 

 

kextstat | grep -v com.apple