MBP UEFI WINDOWS SOUND FIXED!!!!

If anyone is still interested I have found the solution for audio on MBP 2011 Windows 10 UEFI installs - it has taken me 4 years to figure out. I was given the answer from a tutorial only adjacently related -here:

https://egpu.io/forums/pc-setup/fix-dsdt-override-to-correct-error-12/

essentially what we knew was that windows didn't 'see' the correct audio devices when booted in pure efi-

The part that was frustrating to me was that many users like myself have lots of UEFI installs on their 2011 MBP and those OS's have no problem 'seeing' the HD audio controller -

So what was windows doing different?

I had messed around with mm commands in a UEFI shell (The shell provided in the rEFIt package) to no avail*

I had tried to pass SETPCI commands from grub into Windows 10- no luck*

A quote from the link above got my brain spinning

"A Windows system's DSDT table root bridge definition (ACPI PNP0A08 or PNP0A03) is usually confined to a reserved 32-bit space (under 4GB) budgeted to be large enough to host the notebook's PCIe devices. A watermark TOLUD value is then set and locked in the system firmware. Windows OS honors the root bridge definition and will allocate PCIe devices within it. macOS ignores the root bridge constraints as too does Linux when booted with the 'pci=noCRS' parameter. Neither of those OS require a DSDT override and can allocate freely in the huge 64-bit PCIe address space"

So Windows 'honors' the root bridge and OSX and linux disregard it --hmmm interesting.

As someone who also deals in hackintoshes I am very aware of DSDT's and how editing them can help get OSX running on home brew PC hardware- I had played around with installing Clover (the UEFI bootloader almost synonymous with Hackintoshes) on USB thumb drives and putting the DSDT from my MBP 2011 in the /Clover/ACPI/Windows folder - still nothing-- I thought that pointing windows to a DSDT would be enough.......

A side note is that there are people who have 'bricked' their real Macs when using clover, I have never had that issue personally (a sub-link in the link above describes such a situation)*

If you follow the guide and make a modified DSDT (one that add 'qwords' to the dwords section) you can test it in two ways-

I used Maciasl to extract and edit my DSDT to add a 'Qword' section - I placed the DSDT in two locations /EFI/Clover/ACPI/Patched [not sure if that one matters] & /EFI/Clover/ACPI/Windows

holding ALT/option during bootup I selected "EFI Boot" from the USB clover and booted into Clover

for the exact Clover configuration send me a message

After booting into windows the sound card was immediately working (this was because I had installed the cirrus logic drivers from bootcamp 4) - the display audio driver in device manager had an exclamation point but I was able to install the display audio driver from intel's driver support for the i7 2470m CPU in this machine-

I also looked at device manager via 'by resources' and saw that a new entry 'Large memory with an address range appeared

And low and behold the address range for the 'large memory section' contained the range for the hd audio controller

I then wanted to see if the method described in the initial link posted above where you force that memory map into the registry and turn on 'test signing' worked --

it did, which allowed me to boot directly into windows without the help of clover --

*NOTE: when I tested the registry method I skipped the first few steps since I already had a modified DSDT- I did need to create the 'C:\dsdt folder and extract the windows binaries to that folder - but I did not use their acpi dump nor compiler (I check for errors and compiled my dsdt in Maciasl in OSX)

I would gladly go more in depth but I doubt there are many more who need this information- just glad to have figured it out without the BIOS emulation of bootcamp- going to test this method on other 'pre 2013' Macs with non complient UEFI bios'