Yes, I actually dual boot very often. I’ll have to give your cold boot solution a try and see what happens. Nice catch!
1 Like
@Hubro Well look at that! A complete cold boot seems to work, at least it worked for me first try. So it indeed appears that there’s something about booting into Windows that leaves the audio unstable in some way. Great testing! Thanks!
2 Likes
That is good news! Thanks for the information! Can you please post which Windows audio driver version (It’s the one for the High Definition Audio Device - hwid=10ec:1220/1458a0cd) you are using? As I do not have this problem I would like to know what the difference is between our setups.
IDs:
HDAUDIO\FUNC_01&VEN_10EC&DEV_1220&SUBSYS_1458A0CD&REV_1001
HDAUDIO\FUNC_01&VEN_10EC&DEV_1220&SUBSYS_1458A0CD
Details:
Realtek Semiconductor Corp.
12/3/2019
6.0.8854.1
Microsoft Windows Hardware Compatibility Publisher
1 Like
I’m not sure how I specifically check what driver a device is using, but I do have Realtek High Definition Audio Driver (6.0.8862.1) installed, so I assume that’s what’s being used.
Also while I’m at it I checked by BIOS version: F11 (12/06/2019, SAMTS002)
1 Like
@DigitalYeti @Hubro Thank you for the driver information!
Ok, my hypothesis is: On a cold boot, the HDA driver for the ALC1220 in conjunction with the clevo quirk (ALC1220_FIXUP_CLEVO_P950) works fine. Rebooting from Windows, the driver also works fine if using Microsoft’s generic HD Audio driver.
However, rebooting from windows with the device-specific Realtek driver (at least versions 6.0.8854.1 and 6.0.8862.1) breaks the audio somehow. My best guess is that the Realtek driver messes with the HDA pin_config or HDA verbs which it does not reset when shutting down or rebooting which make them persist into the Linux OS. The linux driver does not expect the state of the audio hardware to be non-default (default would be the way the uEFI initializes the audio hardware) and therefore cannot recover from that scenario.
Solution: Use Microsoft’s generic HDA driver on Windows. It works fine - I am using it since I got this board and do not miss anything. However, I do not use Windows that much so there may be corner-cases where the Realtek driver may be better - I just don’t know.
On a side-note: It may also be possible to teach the linux driver to recover from an unclean audio hardware state. However, IMO the problem should be fixed on the Windows side. Adding another quirk just because a driver on Windows does not clean up after itself feels wrong to me. Especially when one driver does it right and the other does it wrong…
Input welcome.
I’ve given it a bit of thought, and I feel like the OS should be responsible for resetting a device to its expected initial state upon boot.
Yes, I agree that the Windows driver is probably “to blame” in this particular scenario, but there are probably lots of other ways the device could end up in an unexpected state, for example if the PC bluescreens, or if somebody hits the reset button so the Windows driver doesn’t get the opportunity to clean up after itself.
On a sidenote, I have now completely stopped rebooting the PC since I realized that it’s possible for internal hardware to maintain state. Instead I power the PC off completely before powering it back on to switch OS. Not only has this completely eliminated the sound issue in Linux, but I don’t think Apex (the game I mostly reboot to Windows for) has crashed a single time since I made this change. This game usually crashes several times in a 3-4 hour game session.
Granted, I have only played perhaps 10-12 hours of Apex since I stopped rebooting, but it seems promising. It wouldn’t surprise me at this point if the Linux driver puts the GPU in a state where it’s more likely to crash in Windows if not properly reset.
1 Like
Sorry to necro this thread, but the number of people using this board on Linux seems pretty small and I figured some extra confirmation wouldn’t hurt.
I’ve been able to confirm that the cold boot solution works, and it certainly seems to be the Realtek drivers that are causing the issue. I uninstalled the drivers on Windows and used the Microsoft drivers. These don’t seem to cause the no audio issue in Linux.
Fun little tidbit: After uninstalling the Realtek drivers, I rebooted Windows and after the reboot, the Microsoft drivers exhibited the same no audio issue! Doing a cold boot resolved the issue in Windows the same as it did in Linux.
While I think it would be great if the driver could handle the bad state that the Realtek driver leaves the card in, at least it’s roughly at parity with the MS driver in that both refuse to play audio when the last driver in use was the Realtek one.
2 Likes
I am looking to buy this motherboard for my new PC. It will be used with Linux as primary System and a host to Windows guest with VFIO.
I intend to switch between multiple sound devices, 7.1 speakers / wireless headphones / sound over HDMI.
have the sound issues been fixed by now?
I am not looking forward to another sound nightmare in Linux…
thanks.
If you don’t dual boot Windows, everything should be working as expected now. If you do dual boot with Windows, make sure you cold boot (power off then power on) rather than reboot and you should be fine.
1 Like
I’ve joined the forums after finding this thread in a search engine result, I am having a similar problem.
My system is a Ryzen one but an NVidia GPU. The motherboard is a Gigabyte X470 Aorus Gaming 7 wifi, with a 3900X. GPU is a RTX3080. Like the other posters I dual boot with Windows 10, but I have to manually run alsamixer and unmute the headphones channel when I boot into Linux. I am using the Windows provided Realtek driver, not the one from Gigabyte. The Realtek chipset is an ALC1220.
I have seen the posts suggesting a cold reboot might fix it and that is not my experience. I can leave the computer powered down and switched off at the mains socket, boot straight into Manjaro and find the problem exists.
Currently running Manjaro, with the 5.13.19-2-MANJARO kernel and Plasma 5.22. Having said that, I do not believe this is distro specific. I have tried a USB boot drive with X64 Ubuntu 21.10 on it, plus a recent download of Endeavour OS and also Pop OS 21.04 (Nvidia drivers version). My gut feel is that Pulseaudio is not playing nicely with Alsamixer, not that this is caused by dual booting beforehand?
If there is a chance of this being solved, or I can help someone more knowledgable than me diagnose further, I am more than happy to help. I used Linux years ago back in the days of Ubunutu Dapper Drake etc, but only recently started using it again. I’m not a total noob, but equally no Linux sysadmin!
$ pulseaudio --version
pulseaudio 15.0
Here is the list of what’s installed in my system, but I have tried removing the USB FiiO headphones DAC and it makes no difference to the problem. My headphones are plugged into that USB DAC, not a headphones port on the motherboard/case front. The speakers are plugged into the analog line out port on the motherboard rear.
$ cat /proc/asound/cards
0 [NVidia ]: HDA-Intel - HDA NVidia
HDA NVidia at 0xfc080000 irq 113
1 [Generic ]: HDA-Intel - HD-Audio Generic
HD-Audio Generic at 0xfc900000 irq 115
2 [C920 ]: USB-Audio - HD Pro Webcam C920
HD Pro Webcam C920 at usb-0000:0d:00.3-1, high speed
3 [Audio ]: USB-Audio - DigiHug USB Audio
FiiO DigiHug USB Audio at usb-0000:0d:00.3-3, full speed
4 [Microphone ]: USB-Audio - Yeti Stereo Microphone
Blue Microphones Yeti Stereo Microphone at usb-0000:0d:00.3-4.1, full speed
And if I try reinitialising Alsa:
$ alsactl init
alsa-lib parser.c:242:(error_node) UCM is not supported for this HDA model (HDA NVidia at 0xfc080000 irq 113)
alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -6
Found hardware: "HDA-Intel" "Nvidia GPU 9a HDMI/DP" "HDA:10de009a,10de1467,00100100" "0x10de" "0x1467"
Hardware is initialized using a generic method
alsa-lib parser.c:242:(error_node) UCM is not supported for this HDA model (HD-Audio Generic at 0xfc900000 irq 115)
alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:1 use case configuration -6
Found hardware: "HDA-Intel" "Realtek ALC1220" "HDA:10ec1220,1458a0cc,00100101" "0x1458" "0xa0cc"
Hardware is initialized using a generic method
alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:2 use case configuration -2
Found hardware: "USB-Audio" "USB Mixer" "USB046d:082d" "" ""
Hardware is initialized using a generic method
alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:3 use case configuration -2
Found hardware: "USB-Audio" "USB Mixer" "USB1852:7022" "" ""
Hardware is initialized using a generic method
alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:4 use case configuration -2
Found hardware: "USB-Audio" "USB Mixer" "USBb58e:9e84" "" ""
Hardware is initialized using a generic method
Thank you in advance for any help 
1 Like
Sorry but that sounds like a completely different issue. You should probably start a new post.
1 Like
Thanks, will do!
Dual boot x570s Master and find the Win driver condition has no effect.
Most definitely an alsamixer issue.
5.15.2-2-MANJARO
Hello all,
I am the author of the initial patch which enabled audio and I am currently working on a revised version of my patch which handles the missing audio when rebooting from windows. Turns out the Realtek drivers on windows change some of the HDA Coeffs and the firmware (UEFI) does not correct them at reboot-time. As a result, they must be corrected on the linux-side. For the mean-time I prepared a script which fixes the audio as I am trying to upstream the new quirks to linux.
Workaround-script
#!/bin/sh
hda-verb /dev/snd/hwC2D0 0x20 SET_COEF_INDEX 0x1a
hda-verb /dev/snd/hwC2D0 0x20 SET_PROC_COEF 0x01c1
hda-verb /dev/snd/hwC2D0 0x20 SET_COEF_INDEX 0x1b
hda-verb /dev/snd/hwC2D0 0x20 SET_PROC_COEF 0x0202
hda-verb /dev/snd/hwC2D0 0x20 SET_COEF_INDEX 0x43
hda-verb /dev/snd/hwC2D0 0x20 SET_PROC_COEF 0x3005
Just be sure to check if hwC2D0 is actually your device (could also be hwC0D0 or somethin else)
Oh and if there are people with X570 Extremes or X570s Masters which want to give the script a shot and tell me if it worked for them I could also make a patch so linux will do that automatically for them too.
UPDATE: Well, let’s see if it is being accepted: LKML
5 Likes
Confirming, workaround hda-verb script is working on my X570 Master after rebooting from Windows 10 with Gigabyte Realtek driver.
Thank you, hope it gets accepted to kernel ASAP!
1 Like
Good news! The second revision of the patch has been accepted: LKML.
People who build their own kernels can apply the patch right away if they want to. It is currently only working for X570(non-S) Masters though.
Again, I would love to fix X570 Xtremes and X570S Masters and maybe other boards if people out there which own them would like to test 
.
3 Likes
I’m kinda curious why this would seem to be a Gigabyte board specific issue?
I mean the ALC1220 realtek chip is used on pretty much any other board.
Seems like a Gigabyte driver specific problem then or at least what Windows is doing to it.
But it’s kinda strange that other brand / model boards with the same audio chip,
not running into those issues as well. 
Kinda interesting to say the least.
Have a look at patch_realtek.c which is full of quirks like the one I did. And this is just for Realtek codecs!
I cannot tell you the reasoning for why these X570 Gigabyte boards need this kind of special treatment but this is how hardware and drivers work in general. If the hardware has a problem - be it because it is faulty by-design (Intel I225-V cough) or it was integrated in a non-standard way - the driver must take care of it because it is way cheaper to workaround hardware quirks than redesigning and re-manufacturing it.
1 Like
