Return to Level1Techs.com

Has anybody gotten audio working in Linux on Aorus X570 Master?

FYI: My sound stopped working this morning with the nouveau driver as well.

Alright, I booted my PC just now and audio through the X570 doesn’t work.

I disabled and stopped pulseaudio:

systemctl --user disable --now pulseaudio.socket pulseaudio

I confirmed pulse is no longer running and no longer autostarting.

I listed my devices:

➜ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 10: HDMI 4 [HDMI 4]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: HDMI [HDA ATI HDMI], device 11: HDMI 5 [HDMI 5]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Generic [HD-Audio Generic], device 0: ALC1220 Analog [ALC1220 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Generic [HD-Audio Generic], device 1: ALC1220 Digital [ALC1220 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: S840 [SteelSeries Siberia 840], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

I tried playing audio through my X570 audio card using aplay:

➜ aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Right.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

Nothing. Complete silence. So it doesn’t seem to be Pulse’s fault?

To confirm the issue isn’t anywhere else, I tried playing the sound through my monitor (HDMI) and it works:

➜ aplay -D plughw:0,10 /usr/share/sounds/alsa/Front_Right.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Right.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono

I guess I’ll keep rebooting until hopefully the audio works :weary:

EDIT: Rebooted my PC 3 times with no luck. Then I decided to cold boot my PC. I shut off the PSU power switch and pressed the power button a few times and waited about 30 seconds. When I booted the PC audio now works. Can this have something to do with me dual-booting Windows, and Windows setting the audio card in a state that screws things up in Linux?

This is all so weird… How can it just stop working all of a sudden? I really do not understand what’s going on - especially because I never had any problems with the audio after applying the quirk in my setup. I am really sorry you experience these problems. Did the audio work again at any later point in time? Also, can you please try the latest stable v5.5.9 Kernel (which already includes the audio fix)? Thanks!

See the edit at the bottom of my answer above. Do you think this could be relevant?

@DigitalYeti Do you also dual boot Windows? Does cold booting fix your audio issues?

Hi again. Your patch has been working perfectly for the last few weeks, but yesterday I booted into Windows to play some games, and I rebooted back into Arch afterwards, and the audio was borked again. There was no way to get audio out my speakers, no matter if I chose speakers or headphones.

And again, shutting my PC all the way off, leaving it for a few seconds and then booting it again (using your patched kernel), fixed the problem. So it definitely seems that rebooting straight from Windows and into Linux has the audio card in a state where it doesn’t function in Linux.

1 Like

Hi @Hubro,
oh, that is actually good to know - especially because there is a working workaround. Maybe the Windows driver does something special which the linux driver cannot recover from -> which would explain why audio does not work after rebooting from windows but actually does work on a cold boot.
I also have a dual-boot setup with Windows 10 1909 (which I rarely use because steam play is amazing) and did not once experience these problems. So maybe I have a different driver which does not cause these problems. When I am done working I will check and post my Windows driver version. Oh, and maybe it is even uEFI related? Do you have the F11 uEFI?.

UPDATE: The driver I use on Windows 10 1909 is Microsoft’s generic HdAudio.sys version 10.0.18362.356 . I did not install the Realtek driver from GigaByte’s website.

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:

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