Losing macOS audio when rebooting in Windows, audio returns when booting into Linux

[XgamesMFZB]

Found a similar thread upon ressearch, but unresolved: https://forum.amd-osx.com/index.php?threads/problem-with-dual-alc1220-audio-codecs.1420/

Hi all,

I've been having this problem since I started this Hackintosh on Big Sur & Catalina. Now I use Monterey 12.1 (Specs in my signature).

macOS audio is definitely working perfectly with AppleHDA (No VoodooHDA), until I reboot into Windows 10 (same SSD), then if I reboot into macOS later, the volume up/down animation will play as normal, but no sound at all. The sound is lost until I reboot into Linux Mint it appears and access macOS again, audio will return.

boot-args: keepsyms=1 debug=0x100 agdpmod=pikera npci=0x2000 alcdelay=1000

Previously, I used alcid=7 with success in the bootargs, and so I decided to improve it following the Dortania guide and removing the bootarg ( https://dortania.github.io/OpenCore...al/audio.html#making-layout-id-more-permanent ). This has been successful. I also managed to add the boot chime to the picker successfully. What I can tell is that the boot chime will work, until I reboot into Windows, then when I reboot again, I'll lose the boot chime (Actually it does play, only garbage) and will also lose all audio in macOS... that is until I reboot into Linux again. It seems that the audio is breaking very early on in the boot process then if the boot chime doesn't even play.

Any clue? Do I need to provide my full config.plist / ioreg ?

Much appreciated,

<dict>
<key>DeviceProperties</key>
<dict>
<key>Add</key>
<dict>
<key>PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x4)</key>
<dict>
<key>layout-id</key>
<data>
07000000
</data>
<key>alctsel</key>
<data01000000</data> (As recommended here, as this is the same problem: https://dortania.github.io/OpenCore...html#applealc-not-working-from-windows-reboot )
</dict>
</dict>
<key>Delete</key>
<dict/>
</dict>
</dict>

 

[makabaka]

lol,I also find the same proplem.actually i have no idea of solution！

 

[Edhawk]

Shutdown the system instead of restarting/rebooting. Specifically when switching from one OS to another.

That way the drivers from Windows are completely stopped and not carried over to macOS.

This is an issue that more often occurs with Bluetooth devices, but does effect Audio too.

 

[XgamesMFZB]

Shutdown the system instead of restarting/rebooting. Specifically when switching from one OS to another.

That way the drivers from Windows are completely stopped and not carried over to macOS.

This is an issue that more often occurs with Bluetooth devices, but does effect Audio too.

Ah right, this work as well, thank you for another temporary solution.

 

[Edhawk]

This isn't a Temporary solution. It is THE solution!

You are running an AMD Hack, that triple boots macOS, Windows and Linux it is never going to be plain sailing, you should expect some inconstancies.

Shutting down the drivers from one OS, before booting in to another OS, should be expected if there are to be no conflicts or snippets of code carried over to the other OS.

Without first shutdown the system to clear everything from the RAM/NVRAM etc. this is never going to happen?

 

[XgamesMFZB]

This isn't a Temporary solution. It is THE solution!

You are running an AMD Hack, that triple boots macOS, Windows and Linux it is never going to be plain sailing, you should expect some inconstancies.

Shutting down the drivers from one OS, before booting in to another OS, should be expected if there are to be no conflicts or snippets of code carried over to the other OS.

Without first shutdown the system to clear everything from the RAM/NVRAM etc. this is never going to happen?

Thank you for sharing your thoughts, you must be right (just upvoted) I thought there was another way but oh well, maybe indeed being NVRAM related it's not easy or indeed a compromise (not sure to be fair, I could be completely off-track hehe, I'm no expert).

AppleALC not working from Windows reboot​

If you find that rebooting from Windows into macOS breaks audio, we recommend either adding alctsel=1 to boot-args or add this property to your audio device in DeviceProperties:

OpenCore manual doesn't say much about what the alctsel property does, it's a shame, would have loved to look into it more myself because the bootarg makes not difference.

 

[Edhawk]

alcsel=1 is the equivalent of AppleALC-Select=True.

Basically the boot argument forces the kext to be loaded, as it can fail to load when rebooting and switching OS.

I don’t think the boot argument resolves the issue where the Windows driver remains in memory and prevents the macOS audio working.