Speaker audio not working until Alsamixer headphone volume manually raised

Software & Operating Systems Linux
, ,
1

I’ve joined the forums after finding the thread Has anybody gotten audio working in Linux on Aorus X570 Master? but have been advised that my issue may be a new one, hence the new thread.

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 in the previous thread 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/Realtek. The Realtek chipset is an ALC1220.

Below is the output from Alsamixer when I boot into Manjaro, showing the headphones volume at 0. If I increase that then the audio starts being played out of my speakers.

Alsamixer showing headphones volume
Alsamixer showing headphones volume1256×976 39.8 KB

Alsamixer showing automute off
Alsamixer showing automute off1256×976 40.3 KB

I have seen the posts in the other thread 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: :grinning:

2

Well, glad it turns out I’m not quite as insane as I thought I am cause I’ve been having that issue for over a year now and it worked previously. No idea what happened. Same board as well.
What I can say though is that it is not related to Dual-booting. I started having the issue long after the last time I booted Windows.

I initially thought it is my configuration but I couldn’t find anything related to it, also tried overriding it in pulse-config, no luck. I thought it might be an issue with Fedora default config, but seeing as you’re on Manjaro that doesn’t seem to be the case.

I then actually went into the terminal during the login screen and noticed the issue is present there already, so it’s not a user configuration.

3

Either that or we are both losing the plot!

As I say, I created a USB bootable drive and tried just booting into a live USB of a couple of ditros, Ubuntu, Endeavour OS and Pop OS. All have the same problem!

Maybe I might try a more up-to-date Kernel if I am feeling brave, but I’m currently on 5.13.19-2 and Ubuntu 21.10 is also 5.13. When I next reboot I’ll check my AGESA version, but I am fairly uptodate. Given you say it’s worked before, I wonder if that might be related?

4

I’m on 5.14.9 and it’s still happening so yeah…

Well this install started with Fedora 27 28 and has been upgraded from there, currently on F33.

If you’re bored you’ll see I had a myriad of other sound-related issues before (which is why I thought my settings are just messed up), but the current situation with the ALSA mixer started with F32.
Checking DNF history tells me the upgrade went from Kernel 5.5.15 to 5.6.10, while ALSA version remained the same with 1.2.2, and pulse with 13.99.1 was unchanged as well.

I’m wondering if it’s just an issue with this specific board as I haven’t read of anyone else having this issue. Maybe it just doesn’t register to the system that there’s something plugged in properly.

1 Like
5

I wonder if I could find a distro image for an old version of Fedora or other distro and try live booting from that? I’m working at the moment so it’s not fair to spend a lot of time on this, but might give it a try later :+1:

6

https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/28/Spins/x86_64/iso/

7

I copied the KDE Fedora 28 iso to a USB drive and made it bootable. The behaviour was slightly different - I was able to get audio from line out/my speakers if I made line out the default audio channel and directed the audio to ‘headphones (unplugged)’.

So it looks like Pulseaudio is somehow getting confused between the headphones and line out channels, directing the audio to the opposite channel than it should. Pulseaudio seems to realise the line out is plugged in though, or at least pavucontrol would suggest it is!

8

I think that’s how it is for me? But I’m not sure how you separate the two.
Line Out and Headphone (unplugged) are listed as “ports” of the same audio device so I can only choose either one of them. Line Out has been the default for me since… forever, because changing it to Headphone would reset it on a reboot because Pulse seems to think it’s unplugged.
That said, for me it doesn’t even seem to matter whether I choose Line Out or Headphone, I get sound either way (and I have only one plug used, I’m using a Y-Splitter to my physical speakers and headphones because I just couldn’t get the switch to work properly and also because of virtual devices pointing to the physical device).

Also of note: When switching from Headphone back to Line Out, it resets the Headphone volume in Alsamixer to 0.
In fact it adjusts 4 “sliders” based on whether I choose Headphone or Line Out. Line Out sets Headphone to 0 and maxes out Surround, Center, and LFE, while choosing Headphone does the opposite.
Meaning if we could get the Headphone to be the default choice, this all would probably work out on its own (unless you also want/need the Line Out simultaneously).
Can’t find any config files that control this though.

9

Part of me is thinking about keeping this simple. Given that I can recreate it with a fresh live USB image of Ubuntu 21.10, I wonder if it’s worth a bug report with Canonical and see what they say?

Can you reproduce the problem with a live USB of Ubuntu 21.10?

10

I haven’t tried Ubuntu but seeing as you could also reproduce it in Fedora, I’m not sure it’s distro related.

That’s one thing that bothers me about Linux, never knowing where to report issues…

edit:
also one more issue with switching to headphones: Due to (I assume) it being recognised as “unplugged”, Pulse keeps dragging new audio streams to another audio device when I set it to the Headphone port, and I have to manually assign the audio streams back to the correct device. No such issue with Line Out because it is “plugged in”.
Can we not just not have the choice for once and just have all the channels maxed out all the time? :confused:

11

Do we think this might be related?

[    4.236827] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC1220: line_outs=3 (0x1b/0x15/0x16/0x0/0x0) type:line
[    4.236832] snd_hda_codec_realtek hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    4.236833] snd_hda_codec_realtek hdaudioC1D0:    hp_outs=1 (0x14/0x0/0x0/0x0/0x0)
[    4.236835] snd_hda_codec_realtek hdaudioC1D0:    mono: mono_out=0x0
[    4.236835] snd_hda_codec_realtek hdaudioC1D0:    dig-out=0x1e/0x0
[    4.236837] snd_hda_codec_realtek hdaudioC1D0:    inputs:
[    4.236838] snd_hda_codec_realtek hdaudioC1D0:      Front Mic=0x19
[    4.236839] snd_hda_codec_realtek hdaudioC1D0:      Rear Mic=0x18
[    4.236840] snd_hda_codec_realtek hdaudioC1D0:      Line=0x1a

Am I reading this right - the Realtek codec has identified the speakers connected to the line out as headphones - speaker_outs equally zero and all channels null, whereas headphone_outs (hp_outs_ equals one and the first channel is hex 14?

12

Makes me wonder what happens when you plug the speakers into one of the 3 Line-Out channels (Center, Surround, LFE).
Could just be that everything connected to that plug is a “headphone” by default, and/or that the “headphone” designation doesn’t do anything beyond the name.

It does look the same for me though:

[    6.694193] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC1220: line_outs=3 (0x1b/0x15/0x16/0x0/0x0) type:line
[    6.694197] snd_hda_codec_realtek hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    6.694199] snd_hda_codec_realtek hdaudioC1D0:    hp_outs=1 (0x14/0x0/0x0/0x0/0x0)
[    6.694200] snd_hda_codec_realtek hdaudioC1D0:    mono: mono_out=0x0
[    6.694201] snd_hda_codec_realtek hdaudioC1D0:    dig-out=0x1e/0x0
[    6.694202] snd_hda_codec_realtek hdaudioC1D0:    inputs:
[    6.694203] snd_hda_codec_realtek hdaudioC1D0:      Front Mic=0x19
[    6.694204] snd_hda_codec_realtek hdaudioC1D0:      Rear Mic=0x18
[    6.694205] snd_hda_codec_realtek hdaudioC1D0:      Line=0x1a
13

I don’t think it is a case that everything plugged into the line out gets treated as headphones. If I pull the cable out of the line out port, the audio gets diverted to headphones instead (in this case, my FiiO USB headphones DAC).

I know there was a problem with quiet audio before from Realtek and Gigabyte provided a firmware update, which you can see here:

I’ve already done the IFU_xe32_v1090.zip flash, did it back in 2019. Given that audio is fine in Windows, I’m not sure these problems are related to that firmware?

I am of course just thinking out loud here…

14

What I mean is that there probably is no special treatment and that the “headphone” designation is just a name.
When you pull the plug then alsa/pulse get a signal that they have been disconnected and the device is therefore inactive, so it diverts to the next available audio device. There is a pulse module for when the default audio source dies to do exactly that.

That said, I just noticed something. I don’t think that dmesg log actually tells us what’s connected, but only the available connectors? Because for both of us it also lists 3 line outs. And I don’t know about you, but my 3 line outs (center, surround, LFE) are unused, but still show in that log.

One thing I’m curious about (and I never tested) is if the “Headphone (unplugged)” port ever gets to be “plugged” when using different plugs at the back of the board (or maybe that’s the front-audio connector?).

I mean the audio on Linux is “fine” too, the only issue it has is that muting of the device, and Windows just doesn’t do that. It just leaves the volume alone and sends the audio there and doesn’t care if anything is actually plugged in.
Which arguably is the better situation.
And additionally on windows there’s the proprietary Realtek driver that does who-know-what in the back dealing with weird edge cases or possibly implementation issues from manufacturers, so I don’t think the 2 are comparable.

15

Ah, I don’t use the Realtek driver in Windows, found the control software unnecessary and bloated. Just use the standard Windows driver.

My lineouts on the rear are the same - the only ones used are the pink microphone port and the green audio line out port.

What was interesting however, is that if I plug a set of headphones into the front panel headphones jack, PAVU control recognises a device has been ‘plugged in’ and not both show connected, rather than headphones ‘unplugged’.

In pavucontrol I can then switch the line out to be going to my headphones, but I still have to go into alsamixer and increase the volume of the headphones as before.

But as soon as I switch back to line out (speakers) in pavucontrol, the audio is really quiet - and that doesn’t matter whether it’s speakers or headphones. I have to run alsamixer again and increase the volume.

16

If I remember correctly from the last time I had dug into audio stuff the “Headphone (unplugged” port IS the front audio connector, but don’t quote me on that.

Just remembered this and could be my faulty memory so take it with a grain of salt, but I believe it only shows the front panel connection as a separate headphone connection when you configure it so that you can have a different audio stream being output on the front panel audio than the back panel. Could be that or something else, but I do remember it not functioning intuitively so something to fool around with.

Wonder if it’s something with the specific implementation of the ALC1220 on Gigabyte boards that is causing this because I have the same chipset on my ASRock X570 Taichi, but none of these issues. Let me just clarify that as far as I am aware on Pop!_OS 20.04 I have NO audio issues with the ALC1220 that I am aware of.

17

It would certainly seem to be the case Velgen! I bought this motherboard based upon the rave reviews of the VRMs, but have to say it’s not been the best of experiences. I had problems in Windows until I flashed the Realtek firmware with an updated one provided by support, the RGB on the board is ‘temperamental’ and now this issue with audio in any Linux distro I’ve tried. I had Gigabyte motherboards donkeys years ago, but in between have mostly been Asus and MSI.

Gigabyte have recovered from the ransomware attack on their support site, haven’t they? Part of me is thinking about opening a support ticket, they can easily reproduce the issue with a live USB of Ubuntu, so wouldn’t need a complicated test case.

18

That is still the Realtek driver, don’t need their Control panel for that :wink:

This is what I was saying too, when I switch between the two it mutes different channels depending what output I choose.

That would sort of make sense, but the thing that doesn’t make sense then is why changing the Port in pavucontrol (or KDE’s sound control for that matter) then still plays the sound on the lineout port unless it’s always playing them at both. But in that case, why does the selection exist in the first place? And also remember the “headphone” line in alsamixer is the one adjusting the lineout plug’s volume. So nothing really seems to match up properly.

Yeah that’s what I am suspecting too and why this issue comes up rarely. I mean, the chance of finding someone with the same board and on Linux is small to say the least.

19

This depends on settings you can configure it so that it is always outputting on both ports, but if you don’t then it just relabels “Line Out” as headphone under the hood though it’s still line out from my understanding. Been a bit since I really dug into this, but I do know there is some setting in the sound control panel (can’t remember if it’s in pulse or alsa) that if enabled outputs on both at the same time from some testing I did few years ago. Just popped into my head, but I think there are 2 listings of headphone in the sound config files one is the dummy one for when it relabels lineout as headphone to remember your headphone settings, and the other is if you tell it to have separate audio streams/outputs for front panel and lineout. Something along those lines am at work so I can’t visibly look at the files to confirm things and am just going on my horrible memory.

Just seems weird that a manufacturer can implement a chipset in such a way that it’s buggy. One would think if they followed everything to spec it should just be the same as everything else, but definitely doesn’t seem to be the case with all the various weird issues people end up experiencing on various boards and systems across brands.

20

Yes, perhaps I should have said “the Microsoft provided driver”.

Can you do me a favour? Can you boot into Fedora, with your audio not working and then run:

sudo alsactl -init

When I run that, instantly the audio starts playing from my speakers.

1 Like