No sound from speaker but audio expansion module and bluetooth headphones works, how to troubleshoot?

[Christian_Eriksson]

I’ve recently received my Framework 16 DIY, and I’m having some audio issues. I’m getting sound from my bluetooth headset and I also get sound when I plug a headset into a audio expansion module but for some reason I don’t get any sound from the internal speakers of the laptop.

My system:

• Framework 16
  • Ryzen AI 300 (for some reason there was no tag for this SKU, if any one could create it I’ll add it to the topic)
  • Geforce 5070
• Arch Linux

What I’ve tried:

• Rebooting (worth a shot)
• Re-seated the speaker connector, I couldn’t see any signs of damage (on connector, cable or board) or that it wasn’t connected before.
• Installed the following packages (I assume I don’t need a few of them but I don’t think that they should be in conflict)
  • pipewire
  • pipewire-docs
  • pipewire-audio
  • pipewire-alsa
  • pipewire-pulse
  • pipewire-jack
  • pipewire-libcamera
  • wireplumber
  • alsa-firmware
  • alsa-utils
  • sof-firmware
  • qpwgraph
  • pavucontrol
  • bluez
  • bluez-utils
  • bluez-deprecated-tools

I believe I have the default configuration for these services, but I can provide them if needed. I did try to change/usr/share/alsa-card-profile/mixer/paths/analog-output-speaker.conf and set the volume for [Element Headphone] to merge as per this suggestion but it didn’t help so I set it back to off.

I’ve tried to verify that the audio device is recognized. I can find a reference to “Ryzen HD Audio Controller Headphones”, see below:

I find this a little strange since on my old laptop I would see something like “Built-in Audio Analog Stereo” and the port would say “Speakers” instead of “Headphones” (though I would be able to choose “Headphones” in my old laptop) as it does in the framework. Is this intended or am I missing some firmware or configuration? There is also no option to choose anything other than “Headphones” on the Framework.

I can see the lower blue indicator move when I play audio so it seems to me like audio is passed to the device, it is just that I can’t hear it. How can I find out if my device is accidentally muted or deactivated? It doesn’t look like it in pavucontrol and my indicator in waybar shows that volume is set to a reasonable 40%, I’ve tried maxing it as well.

What else can I do to troubleshoot this or is it likely that there is some sort of hardware issue?

EDIT: I believe one more thing I could try is to boot into a live Ubuntu environment and see if that works. I’ll report back on that as soon as I can.

[Christian_Eriksson]

Ok, so it seems it is a configuration/software issue. When live booting into Fedora 43 (had a thumb drive handy so went with that instead of Ubuntu) the audio works as expected. Now I guess I’ll have to figure out what is different between my config and Fedora’s config.

[Christian_Eriksson]

I found the issue, for some reason it looks like (at least on my system) the wrong profile for the sound card was chosen by default (I have not changed it previously).

The process to figure it out looked something like this (with a few twists, turns and detours removed)

I checked the installed packages on both systems and they were more or less the same (in terms of audio related packages). I also check which driver was used and the same driver was used.

When checking what sinks were detected, pactl list short sinks, I noted that Fedora classified the sink as Speaker, while Arch (as I had already noted) classified it as Headphones.

Arch:

61	alsa_output.pci-0000_c2_00.6.HiFi__Headphones__sink	PipeWire	s32le 2ch 48000Hz	RUNNING

Fedora:

108	alsa_output.pci-0000_c2_00.6.HiFi__Speaker__sink	PipeWire	s32le 2ch 48000Hz	RUNNING

In Fedora I noticed that the audio controller device was called something like “Family 17h/19h/1ah”, I believe I saw this in pavucontol or it could have been through wpctl status. I ran alsa-info.sh on both Fedora and Arch then diffed the two outputs, something like:

alsa-info.sh > fedora-output
# and same on arch (carrying over fedora output on a thumb drive)
diff arch-output fedora-output

In the diff I saw these lines:

165c168
< c2:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Ryzen HD Audio Controller [1022:15e3] (prog-if 00 [HDA compatible])
---
> c2:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h/19h/1ah HD Audio Controller [1022:15e3]

I then checked pactl list cards on the Arch system and found the alsa_output.pci-0000_c2_00.6 card. Here I could see that there were multiple profiles for the card:

off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
HiFi (Headphones, Mic1, Mic2): Play HiFi quality Music (Headphones, Mic1, Mic2) (sinks: 1, sources: 2, priority: 8500, available: yes)
HiFi (Mic1, Mic2, Speaker): Play HiFi quality Music (Mic1, Mic2, Speaker) (sinks: 1, sources: 2, priority: 8400, available: yes)pro-audio: Pro Audio (sinks: 1, sources: 2, priority: 1, available: yes)

and for some reason HiFi (Headphones, Mic1, Mic2) was selected by default and not HiFi (Mic1, Mic2, Speaker). I’m not sure if this is just for me or for others as well. One can select the correct profile in the pavucontrol GUI (under Configuration) or one can do what I did and create a config file in /etc/wireplumber/wireplumber.conf.d/51-force-speaker-profile-as-default.conf that looks like this:

monitor.alsa.rules = [
  {
    matches = [
      {
        "device.name" = "alsa_card.pci-0000_c2_00.6"
      }
    ]
    actions = {
      update-props = {
        "device.profile" = "HiFi (Mic1, Mic2, Speaker)"
      }
    }
  }
]

It will make sure that the Speaker profile is selected for the device.

After this I rebooted and once logged in again audio works as expected.

[eiis1000]

Thank you for this post, I was having the same issue on NixOS - spent almost ten hours trying to fix it! I also concluded that alsa was applying the wrong settings, since alsamixer showed my speaker as muted and I could unmute manually it to get sound; this meant I could just set it to unmute by default and that would resolve things, but that felt quite brute-force and I wanted to avoid it. Your solution is much better. Consequently I put this in my configuration.nix (though it does still feel a bit hacky):

services.pipewire.wireplumber.enable = true;
services.pipewire.wireplumber.extraConfig.speakerProfile = {
  "monitor.alsa.rules" = [
    {
      matches = [ { "device.name" = "alsa_card.pci-0000_c1_00.6"; } ];
      actions = {
        "update-props" = {
          "device.profile" = "HiFi (Mic1, Mic2, Speaker)";
        };
      };
    }
  ];
};