boot-arg ngfxnoaudio does not prevent AppleALC naming of HDAU audio device

[TonyC5]

Problem: My hackintosh using OC0.8.7 (full specs below) experiences a significantly extended boot cycle when AppleALC renames audio device at pci10de,be3 to HDAU. I have attempted to use boot-arg "-ngfxnoaudio" documented here, but with this boot-arg, AppleALC still names device HDAU. A search through the AppleALC 1.7.7 and WhateverGreen 1.6.2 source code reveals that the boot-arg is not referenced anywhere in the code. In fact, a search for both boot-args "-ngfxnoaudio" and "-ngfxnoaudiocon" mentioned in the document and for IOreg properties "no-audio-autofix" and "no-audio-fixconn" reveals that none of these properties are referenced in AppleALC or WhateverGreen source code. Note that I only want to disable naming of HDAU. I do not want to disable patching / enabling HDEF.

Testing: Add boot-arg -ngfxnoaudio in OC0.8.7 EFI with AppleALC.kext enabled. Boot macOS (tested with Big Sur). Observe that AppleALC has named pci10de,be3 to HDAU. Disable AppleALC.kext and repeat test. Without AppleALC.kext, device pci10de,be3 is not named HDAU.

Temporary Fix: In order to achieve the fix that I believe is supposed to be enabled by boot-arg -ngfxnoaudio, I commented out the HDAU naming in AppleALC's kern_alc.cpp:

When the HDAU naming is commented out in AppleALC, AppleALC does not name pci10de,be3 to HDAU and my hack boots quickly as desired. With this temporary fix, AppleALC's HDEF functionality is unaffected, so AppleHDA is still able to attach to HDEF and internal audio works as desired.

My system specs:

• Dell Latitude E6410 with Nvidia G3100m graphics
• OpenCore version 0.8.7
• SMBIOS MacModel MacBookPro6,2
• AppleALC version 1.7.7
• My baseline EFI is not using WhateverGreen (I have patched GFX0 with an SSDT), but I tested with and without WhateverGreen 1.6.2. Regardless of whether I inject WhateverGreen.kext, AppleALC.kext 1.7.7 still renames device HDAU when I use boot-arg -ngfxnoaudio.
• macOS Big Sur 11.7.1

[abenraj]

-ngfxnoaudio boot-arg was once part of NvidiaGraphicsFixup (ver 1.2.1), which I believe got deprecated during merge into WEG. I believe the rename to HDAU function (now refactored into AppleALC) also originated from NvidiaGraphicsFixup (96fd6fe).

From what I understand, this boot-arg was intended to drop all patches to Nvidia's digital audio device including the rename to HDAU, but now that its deprecated post all the refactoring to WEG and ALC, this particular patch is no longer available to Nvidia users.

In any case, this particular info documented on WEG's Nvidia page leads to confusion and is perhaps in need of an update.

[TonyC5]

@abenraj That explains it - thanks. If this issue is converted to a feature request, I'd like the feature to allow separate enabling/disabling of HDAU rename and HDEF patching (i.e., disabling HDAU rename should not disable HDEF patching and vice versa).

[vit9696]

The freeze means your firmware does not initialise HDAU device correctly. I suggest you simply inject class-code FF FF FF FF into your HDAU device and disable it.

[TonyC5]

@vit9696 Thank you for the suggestion. Changing class-code to FF FF FF FF does prevent AppleALC renaming of HDAU and thus avoids the slow-boot cycle.

Note that I was not able to overwrite class-code via open core 0.8.7 DeviceProperties. I needed to change class-code via an SSDT.

This did not work:

With open core DeviceProperties, I confirmed that I am able to add new DeviceProperties (those not already defined) to device pci10de,be3, but I am not able to overwrite existing properties (even with a DeviceProperties Delete entry in config.plist).

Thank you again for the suggestion.

[vit9696]

This is most likely because there is no name in ACPI for this device. You cannot inject device properties for a device without a name.

[TonyC5]

@vit9696 Thank you - I did not know that. Always reminded that I have a lot to learn. Thanks again and thanks for all you are doing with OpenCore and Acidanthera.

@vit9696 Just to clarify, using OpenCore DeviceProperties, even though pci10de,be3 is not named, I am able to inject new device properties for pci10de,be3 (properties that do not already exist). I am not able to overwrite existing device properties (e.g., I am not able to overwrite class-code which already exists, but I am able to create new property "test" that doesn't already exist).