Return to

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

I recently bought a Aorus X570 Master system and installed Arch Linux on it.

Everything seems to be working famously except for the integrated audio.

It’s detected by Pulse, but when I play audio through it I simply get no sound through my speakers. Or at least that’s what I thought at first, but as I turned my volume to 150% on my PC and cranked my speakers to absolute max I can now actually barely hear the audio coming through my speakers.

Note, this is audio levels that would usually destroy the speakers.

If I boot my PC into Windows, the speakers work fine.

Any ideas?

(I noticed the audio device is handled by snd_hda_intel which sounds like… a conflict of interest? :stuck_out_tongue: Is perhaps the issue that I need a different driver?)

Output of uname -a:

Linux aura 5.5.3-arch1-1 #1 SMP PREEMPT Tue, 11 Feb 2020 15:35:41 +0000 x86_64 GNU/Linux

Output of lspci -nn -vvv:


10:00.4 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller [1022:1487]
        Subsystem: Gigabyte Technology Co., Ltd Starship/Matisse HD Audio Controller [1458:a0cd]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- 
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [64] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
                DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset-
                        MaxPayload 256 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr- TransPend-
                LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 16GT/s (ok), Width x16 (ok)
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not Supported
                         AtomicOpsCap: 32bit- 64bit- 128bitCAS-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                         AtomicOpsCtl: ReqEn-
                LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000fee00000  Data: 0000
        Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [150 v2] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn-
                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
                HeaderLog: 00000000 00000000 00000000 00000000
        Capabilities: [2a0 v1] Access Control Services
                ACSCap: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
                ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
        Capabilities: [370 v1] Transaction Processing Hints
                Device specific mode supported
                Steering table in TPH capability structure
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel


Output of pacmd list-sinks:


    index: 5
	name: <alsa_card.pci-0000_10_00.4>
	driver: <module-alsa-card.c>
	owner module: 11
		alsa.card = "1"
		alsa.card_name = "HD-Audio Generic"
		alsa.long_card_name = "HD-Audio Generic at 0xf7a00000 irq 113"
		alsa.driver_name = "snd_hda_intel"
		device.bus_path = "pci-0000:10:00.4"
		sysfs.path = "/devices/pci0000:00/0000:00:08.1/0000:10:00.4/sound/card1"
		device.bus = "pci" = "1022" = "Advanced Micro Devices, Inc. [AMD]" = "1487" = "Starship/Matisse HD Audio Controller"
		device.string = "1"
		device.description = "Starship/Matisse HD Audio Controller"
		module-udev-detect.discovered = "1"
		device.icon_name = "audio-card-pci"
		input:analog-stereo: Analog Stereo Input (priority 65, available: no)
		output:analog-stereo: Analog Stereo Output (priority 6500, available: unknown)
		output:analog-stereo+input:analog-stereo: Analog Stereo Duplex (priority 6565, available: no)
		output:analog-surround-21: Analog Surround 2.1 Output (priority 1300, available: unknown)
		output:analog-surround-21+input:analog-stereo: Analog Surround 2.1 Output + Analog Stereo Input (priority 1365, available: no)
		output:analog-surround-40: Analog Surround 4.0 Output (priority 1200, available: unknown)
		output:analog-surround-40+input:analog-stereo: Analog Surround 4.0 Output + Analog Stereo Input (priority 1265, available: no)
		output:analog-surround-41: Analog Surround 4.1 Output (priority 1300, available: unknown)
		output:analog-surround-41+input:analog-stereo: Analog Surround 4.1 Output + Analog Stereo Input (priority 1365, available: no)
		output:analog-surround-50: Analog Surround 5.0 Output (priority 1200, available: unknown)
		output:analog-surround-50+input:analog-stereo: Analog Surround 5.0 Output + Analog Stereo Input (priority 1265, available: no)
		output:analog-surround-51: Analog Surround 5.1 Output (priority 1300, available: unknown)
		output:analog-surround-51+input:analog-stereo: Analog Surround 5.1 Output + Analog Stereo Input (priority 1365, available: no)
		output:iec958-stereo: Digital Stereo (IEC958) Output (priority 5500, available: unknown)
		output:iec958-stereo+input:analog-stereo: Digital Stereo (IEC958) Output + Analog Stereo Input (priority 5565, available: no)
		off: Off (priority 0, available: unknown)
	active profile: <output:analog-stereo>
		alsa_output.pci-0000_10_00.4.analog-stereo/#3: Starship/Matisse HD Audio Controller Analog Stereo
		alsa_output.pci-0000_10_00.4.analog-stereo.monitor/#5: Monitor of Starship/Matisse HD Audio Controller Analog Stereo
		analog-input-front-mic: Front Microphone (priority 8500, latency offset 0 usec, available: no)
				device.icon_name = "audio-input-microphone"
		analog-input-rear-mic: Rear Microphone (priority 8200, latency offset 0 usec, available: no)
				device.icon_name = "audio-input-microphone"
		analog-input-linein: Line In (priority 8100, latency offset 0 usec, available: no)
		analog-output-lineout: Line Out (priority 9000, latency offset 0 usec, available: yes)
		analog-output-headphones: Headphones (priority 9900, latency offset 0 usec, available: no)
				device.icon_name = "audio-headphones"
		iec958-stereo-output: Digital Output (S/PDIF) (priority 0, latency offset 0 usec, available: unknown)


I’m struggling with the same problem. I figured out how to force it to work temporarily, but it doesn’t work the way it SHOULD. Here’s the ritual I need to go through:

  • Make sure your speakers are plugged in to the “Line Out” port on the back of the motherboard.

  • Make sure the PulseAudio Volume Control app is installed (via App Center).

  • Open the PulseAudio Volume Control app and click on the “Output Devices” tab.

  • Make sure there are no headphones plugged in to the front audio ports

  • Start up an app with audio output

  • Plug in your headphones in the front headphone port.

  • You should hear sound through your headphones.

  • In the PulseAudio Volume Control app, in the “HD-Audio Generic Analog Stereo” section, you should see a line moving back and forth indicating that sound is playing.

  • While the sound is playing through your headphones, you should see the “Port:” drop-down box has “Headphones (unplugged)” selected.

  • Unplug your headphones and the music will stop, the sound indicator line will stop moving, and the “Port:” drop-down box will have changed to “Line Out (plugged in)”

  • Click the “Port:” drop-down box and change it back to "Headphones (unplugged)

  • You should hear an uncomfortably loud “pop” sound and you should now hear sound through your speakers.

Modifying the output source in any way, “breaks” it again, and I have to go through this whole ordeal again to get sound working again through my speakers.

Hopefully that works temporarily, but I’d still like to actually fix the real problem.
(This was on Ubuntu 18.04 BTW)

1 Like

That’s… fascinating :cold_sweat:

So I guess the current status of drivers just require elaborate dark rituals for audio to work for the time being… Is this bug reported anywhere, and being worked on?

I thought that the audio issue was fixed in 5.4 and upstreamed for 5.5…

Maybe not. take a look at the workaround listed here.

Are you sure this is the same issue? I don’t have any crackling :thinking: My audio volume is just about 1% of what it should be.

I don’t really experience any crackling, just a loud single “pop” whenever the audio source switches, which I’m pretty sure is not supposed to happen since it doesn’t occur in Windows.

I have experienced the very low audio problem as well, and I chalked it up to an issue with the actual routing of the signal. The driver seems to work on a basic hardware level, there just seems to be a problem with routing it to the correct jack under some circumstances. I assumed the low audio was the signal bleeding through from another channel or something similar.

There do appear to be overall problems with how sound is routed to the jacks since I can play around with muting certain unused channels in ALSA and that having an impact on other channels being muted as well for some reason.

I’m not certain that this is a known/reported issue. I’ve seen a few issues related to the ALC1220 in general, but I haven’t seen any related to this specific variant (ALC1220-VB?). If someone could point me towards the appropriate place to report the bug, I’d be more than happy to log it and work with whoever to get it fixed.

Considering how popular this board seems to be on this board, I was surprised that there were still so many outstanding “papercut” issues like this (I’m still also fighting with getting complete hardware monitoring for voltages and fan speeds, and RGB control, but those are obviously different issues).

Yeah, I am not sure but I assume that the same audio solutions for x370 and x470 are used on x570.

Unfortunately I am still on Poor-Dozer with 990FX chipset.

THINK I had the same problem, fought it for days. Finally found a “fix” on unix.stackexchange.
“Audio not working on Gigabyte .570 Aorus Master with ALC1220 and ESS”
Had to follow it to the letter including part 2.
Hope this helps…

1 Like

Hope Gigabyte gives us a “real” fix soon…

What the hell… I was gearing up to try the suggestions in the answers when I tried selecting my “Headphones” port in pavucontrol:

Now the audio is coming out my speakers perfectly clear :confused:

I’m certain I’ve tried that before with no luck…

Definitely some bugs here indeed.

A guy posted just a few days ago on the thread you linked saying he patched the issue:

Have you tried this?

EDIT: It works!!!

(EDIT: I spoke too soon. It sorta worked for a few reboots, but now it’s borked again in a different way. More testing is necessary I guess, but the work-around I posted above no longer works with this kernel patch applied)


Yes, it does seem to work!
Selecting “Line Out” as a source works. Plugging-in headphones into the jack on the front of the case automatically switches sound to the headphones, and unplugging it returns sound back to the line-out.

I was able to successfully patch this into kernel 5.4.23 on Ubuntu 18.04.

Aw… Got me real hyped for a moment there :grin:

I’ve never tried compiling my own kernel on Arch before, guess this is a good time to give it a shot.

1 Like

I’d say give it a try. I did get it to work once, but then it stopped working so I might have done something wrong (I haven’t compiled my own kernel for years).

I have a Gigabyte Z390 AORUS Master with the same issue. Pulseaudio correctly detects which port is being plugged in, but output is sent to the wrong port. To make matters worse, the NVIDIA HDMI sound uses the same kernel module, which tends to confuse pulseaudio as to which device is being used.

Here’s what I did:

  • run pavucontrol
  • under the Configuration tab (all the way to the right - it might not be visible initially), disable any audio devices you don’t intend to use
  • under the Output Devices tab, select Port: Headphones (unplugged)
  • To make the change permanent, edit (with elevated privileges) /etc/pulse/ and add ‘set-sink-port 0 analog-output-headphones’ to the end of the file to set it as the default output.

To list all of the details of your sound devices, you can run pactl list cards. When referencing the device number in /etc/pulse/, be sure to use the value under alsa.card and NOT the initial ‘Card #’ listing. In my case Card#0 was alsa.card = “1” and vice versa.


Thanks! I have an Nvidia GPU as well, so maybe that’s a contributing factor. I’ll give it a try.

1 Like

OK, so here’s what I’ve found: The reason the kernel patch worked the first time I tried it is because the Nvidia drivers weren’t being loaded.

I tried another kernel compile, and the patch just didn’t work. Using Sea_Monkey’s post as an idea, I decided to remove the Nvidia drivers and BAM. Just like magic, the sound is working as expected.

Now I’m going to test with my old AMD video card and see what happens.

1 Like

Yep, audio is fine with an AMD card installed so there’s some sort of conflict there related to Nvidia.

Hooray for binary drivers! :confused:

1 Like

Hi there,
I am the original author of the audio kernel patch and am trying to reproduce your problems with my patch.
I have this patch running for quite some time now and it always worked reliably for me. All it does is apply a quirk for the ALC1220 similar to what other devices like Clevo or MSI laptops need. I don’t see how this interferes with the nvidia binary blobs but I am willing to try investigate this.
Another note, could it be that the previously applied HDAJackRetask workarounds are still intact? These must be disabled as they are obsolete with my patch.
cheers, chris


Just going to quote Sea_Monkey from further up in case you didn’t read that far :slight_smile:

I have no clue about kernel modules though so I have no idea if this matters.