Should AppleALC have a -noHDAU boot-arg to prevent HDAU rename?

[deeveedee]

As I described here, I'm looking for a solution that allows me to use AppleALC.kext with my HackBookPro6,2.  I was able to confirm here that a modified version of AppleALC (one that does not name pci10de,be3 to HDAU) works well with my hack.  With the modified AppleALC.kext, pci10de,be3 is not named HDAU, so AppleHDA does not find a Device HDAU to attach to and boot proceeds quickly.

 

Would it make sense for AppleALC to accept a -noHDAU (or similar) boot-arg that disables naming of pci10de,be3 (or another "HDAU" device) to HDAU?

 

EDIT: For fear of incurring the justified wrath of Acidanthera, I am not going to share my custom AppleALC.kext here.  If you want to build your own to test my solution, download AppleALC.kext source from here and follow the AppleALC.kext build instructions here.  You can easily apply my modification by editing kern_alc.cpp in AppleALC-1.7.7/AppleALC.

Edited December 12, 2022 by deeveedee

[deeveedee]

I am currently running my HackBookPro6,2 (booting Big Sur with OC 0.8.7) with the modified AppleALC.kext 1.7.7.  The modified AppleALC.kext 1.7.7 (with modified kern_alc.cpp) allows my hack to boot very fast while using AppleALC.  As expected, AppleHDA does not find pci10de,be3

 

Spoiler

 

so I only have internal speakers and no audio-over-DP

 

Spoiler

 

but I'd rather have AppleALC with fast boot.

 

Until someone has a way to fix the slow boot problem when AppleHDA detects HDAU on my HackBookPro6,2, having a -noHDAU boot-arg for AppleALC seems like a good idea to me.

Edited December 12, 2022 by deeveedee

[aben]

Given that AppleALC is a must in this scenario, and renaming of device is explicitly performed by AppleALC, then having a boot argument to place a condition on the HDAU-rename function sounds like a pretty viable option as well for these users. 👍

 

For those interested, I was able to create a fork of AppleALC (branch: no-HDAU) that implements a boot-arg (-noHDAU) on the rename condition, thereby forcing the HDEF rename function only. Binaries (for testing or personal purposes) can be retrieved by downloading the Artifacts from GitHub Actions here.

Thanks @deeveedee for the boot-arg idea.

Edited December 12, 2022 by aben

[deeveedee]

@Andrey1970 Is this suggestion for a new AppleALC boot-arg to disable HDAU naming something that Acidanthera would consider?  Thank you.

[feartech]

3 hours ago, deeveedee said:

@Andrey1970 Is this suggestion for a new AppleALC boot-arg to disable HDAU naming something that Acidanthera would consider?  Thank you.

would be no harm in sending a pull request...

[oldman20]

Any ideas for mic line-in and built-in auto switch when jack plugin?

[aben]

8 hours ago, deeveedee said:

Is this suggestion for a new AppleALC boot-arg to disable HDAU naming something that Acidanthera would consider?

Apologies for quoting you here - I'm no spokesperson for Acidanthera, but AFAIK, the suggested approach to go about this (i.e, if you have a feature request or suggestion/idea that could potentially help improve support for those who rely on Acidanthera's projects) would be to EITHER create a post on their bugtracker explaining/pitching why you believe the idea/feature is meaningful/viable for that particular use-case OR submit a Pull Request (if you can implement the idea code-wise) which will be reviewed by developers and actioned upon accordingly. Submitting your suggestion directly gets way better viewability from active members/developers of Acidanthera; one of the many devs might just like and approve the idea, you never know! Surely no harm in trying.

Edited December 13, 2022 by aben

[Slice]

4 hours ago, oldman20 said:

Any ideas for mic line-in and built-in auto switch when jack plugin?

VoodooHDA does this but this is offtopic.

[oldman20]

3 hours ago, Slice said:

VoodooHDA does this but this is offtopic.

thank, impossible with AppleALC?

[Slice]

22 minutes ago, oldman20 said:

thank, impossible with AppleALC?

I am not interesting in AppleALC possibilities.

[deeveedee]

@feartech and @aben If I don't get a response here, I'll follow your suggestion and post in AppleALC github repo.

[Andrey1970]

20 hours ago, deeveedee said:

@Andrey1970 Is this suggestion for a new AppleALC boot-arg to disable HDAU naming something that Acidanthera would consider?  Thank you.

-ngfxnoaudio

https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.GeForce.en.md

[deeveedee]

@Andrey1970 Very interesting, thank you.  I will test this.  Note that the string "ngfxnoaudio" that is referenced as a boot-arg in the WhateverGreen docs is not present in the AppleALC source and it is not present in the WhateverGreen source.  I don't see any code in either kexts that handles/processes the referenced ngfxnoaudio boot-arg.  I'll test and report back here.

 

Thank you.

 

EDIT: @Andrey1970 I tested boot-arg -ngfxnoaudio, using it as documented in your link.

 

Spoiler

 

and found that the boot-arg does not prevent AppleALC from naming device HDAU.

 

Spoiler

 

Since I am not finding the boot-arg in the AppleALC and WhateverGreen source, I suspect that this is a documented feature that was not released.

 

I will continue to test and if I confirm that the boot-arg does not work, I will submit a bug report.

 

Thank you.

 

Edited December 13, 2022 by deeveedee

[deeveedee]

I have not been successful in using the -ngfxnoaudio boot-arg documented in @Andrey1970 's linked document here.  

 

Injection can be switched off by using boot-arg "-ngfxnoaudio" or more specific "-ngfxnoaudiocon". You can also use ioreg properties in GPU to disable respective injections: "no-audio-autofix" or "no-audio-fixconn".

 

When I use the boot-arg, AppleALC still names device HDAU (resulting in the slow boot problem that I reported).

 

I am not finding the boot-args (ngfxnoaudio, ngfxnoaudiocon) or the IOReg properties no-audio-autofix and no-audio-fixconn in the AppleALC and WhateverGreen source code, but I'd still like to test the IOReg properties.  Does anyone know the values that I should assign to the IOReg properties no-audio-autofix and no-audio-fixconn if I want to test them?

 

EDIT: My HackBookPro6,2 does not need WhateverGreen.kext (I fully patch Nvidia dGPU with SSDT), but I injected WhateverGreen.kext 1.6.2 anyway just to make sure I wasn't missing anything.  Even when using both AppleALC.kext and WhateverGreen.kext with boot-arg -ngfxnoaudio, AppleALC still names device HDAU.

 

Kexts

Spoiler

 

NVRAM (with boot-args)

Spoiler

 

Edited December 13, 2022 by deeveedee

[aben]

Upon reviewing the documentation (quite outdated?) and the actual function of the boot-arg in question (which, as you’ve reported, does not seem to be functional) it does seem pretty clear that the use of this WEG boot-arg -ngfxnoaudio is not actually intended to help with your particular use-case. Why? Because it does clearly imply that said boot-arg is intended to prevent injection of HDAU audio properties and connectors, not the rename by AppleALC itself (see alternative suggestions provided to avoid injection of respective GPU audio properties). Like I said in my initial post, AppleALC’s code is currently configured to actively look for any GPU audio device that’s present and explicitly rename to HDAU (most likely to avoid compatibility issues with AppleHDAController), there’s no condition placed to avoid the rename part. Unless of-course you find other routes outside of AppleALC to resolve your issue, either through a kernel patch to stop AppleHDA from further initializing HDAU or via firmware (ACPI/BIOS) to outright disable said device.

EDIT: After lil digging, it turns out -ngfxnoaudio boot-arg was first introduced during development of NvidiaGraphicsFixup ver 1.2.1.. The boot-arg was indeed intended to drop all patches to Nvidia's digital audio device (including the Rename to HDAU patch), which later got deprecated during the merge into WEG. It also looks like the exact Rename to HDAU function (now found in AppleALC code) did actually originate from NvidiaGraphicsFixup as well, post refactoring (see commit 96fd6fe). This means the information outlining the use of -ngfxnoaudio documented on WEG's Nvidia page is simply invalid and outdated.

Edited December 14, 2022 by aben
Info on -ngfxnoaudio (NvidiaGraphicsFixup)

[deeveedee]

@aben Thank you for doing the research!  That makes sense.  With the complexity of all of the Acidanthera development, I'm surprised that we don't see something like this more often.  The Acidanthera product and configuration management is very well done.  Especially in light of the fact that they are volunteers with transient contributors.   I see your response to my GitHub issue.  Let's see how Acidanthera responds.

Edited December 14, 2022 by deeveedee

[deeveedee]

EDIT: Vit9696 indicated that open core DeviceProperties can only overwrite properties for named devices.  Since my Dell Latitude E6410 pci10de,be3 device is not named, OpenCore will not overwrite class-code.  For this reason, I need to overwrite with a SSDT.

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

I followed Vit9696's advice to set device pci10de,be3 class-code to  FF FF FF FF and this does prevent AppleALC.kext from renaming pci10de,be3 to HDAU.  Note that I was unable to overwrite the existing class-code via open core DeviceProperites.  I needed to overwrite with the attached SSDT.  With this attached SSDT, I am able to use AppleALC.kext v1.7.7

 

Attempting to overwrite class-code via OpenCore DeviceProperties does NOT work for me:

Spoiler

 

 

SSDT-HDMI.aml.zip

Edited January 3, 2023 by deeveedee