Sound device not recognized

I have a laptop with an Intel Comet Lake chipset, and until recently, I was having the issue that the built-in speakers remained silent until I plugged in a headphone or a USB audio interface, at which point the headphone, the USB audio and the built-in speakers would work normally, also if I unplugged the extra device again.

Now, I don’t use the onboard audio much, so I have no idea when in the last half year or so this happened, but right now, KDE, ALSA, Pulse and Pipewire all agree that there was no sound device installed.

In more detail:

  • the output of pactl list cards is empty
  • alsamixer shows only the master volume, no devices
  • pavucontrol only shows the virtual joint audio output
    • (independently of whether I use pulseaudio or pipewire)
  • The Plasma audio widget tells me there were no audio sources or sinks

The device is however definitely present:

~ >>> inxi -Aa                                                                                                                                                                             
Audio:
  Device-1: Intel Comet Lake PCH-LP cAVS vendor: Dell
    driver: sof-audio-pci-intel-cnl alternate: snd_hda_intel, snd_soc_avs,
    snd_sof_pci_intel_cnl bus-ID: 00:1f.3 chip-ID: 8086:02c8 class-ID: 0401
  API: ALSA v: k6.12.48-1-MANJARO status: kernel-api with: aoss
    type: oss-emulator tools: alsactl,alsamixer,amixer
  Server-1: PipeWire v: 1.4.8 status: active with: 1: pipewire-pulse
    status: active 2: pipewire-media-session status: active 3: pipewire-alsa
    type: plugin 4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli

This is after switching from Pulseaudio to Pipewire. Before that, I was seeing 3 servers here (Jack, Pulse, Pipewire), with Pulseaudio labelled active. I was wondering whether the issue was related to Pulse, so I switched by installing the manjaro-pipewire package, (which removed the respective Pulse components). This did obviously not help.

I also upgraded the kernel, although I would have been surprised if that had anything to do with the issue. It changed nothing about the symptoms.

If I connect my headphones via Bluetooth, they are recognized by Pipewire and become available as a sound device, but otherwise, everyone seems convinced that there were no sound devices, despite inxi telling me that there is one, and that it has an active driver.

I’ve gone through all the posts around here with audio issues, and tried all the things that I believe were relevant from those threads. I wonder if switching to a different driver could help, but that may just as well be a red herring. I played around a lot with the audio configuration on this Laptop some time ago, there may also be some residual of the modifications I made back then that interferes with the proper working of the system now, although it worked fine at the time (except of course for the system bell being triggered randomly by some mysterious process, which stopped at some point, for equally-mysterious reasons).

Any hints about where to look for pointers or what to try are welcome. Did I miss important diagnostic information? Tell me!

Ooookay, so, of course, after pulling my hair out for a day and asking, I stumble over the fix myself:

sudo dmesg | grep audio finds these lines, among others:

[    6.001549] sof-audio-pci-intel-cnl 0000:00:1f.3: hda codecs found, mask 5
[    6.001555] sof-audio-pci-intel-cnl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
[    6.001557] sof-audio-pci-intel-cnl 0000:00:1f.3: BT link detected in NHLT tables: 0x0
[    6.001559] sof-audio-pci-intel-cnl 0000:00:1f.3: DMICs detected in NHLT tables: 2
[    6.009382] sof-audio-pci-intel-cnl 0000:00:1f.3: SOF firmware and/or topology file not found.
[    6.009386] sof-audio-pci-intel-cnl 0000:00:1f.3: Supported default profiles
[    6.009388] sof-audio-pci-intel-cnl 0000:00:1f.3: - ipc type 0 (Requested):
[    6.009390] sof-audio-pci-intel-cnl 0000:00:1f.3:  Firmware file: intel/sof/sof-cml.ri
[    6.009391] sof-audio-pci-intel-cnl 0000:00:1f.3:  Topology file: intel/sof-tplg/sof-hda-generic-2ch.tplg
[    6.009393] sof-audio-pci-intel-cnl 0000:00:1f.3: Check if you have 'sof-firmware' package installed.
[    6.009394] sof-audio-pci-intel-cnl 0000:00:1f.3: Optionally it can be manually downloaded from:
[    6.009395] sof-audio-pci-intel-cnl 0000:00:1f.3:    https://github.com/thesofproject/sof-bin/
[    6.010623] sof-audio-pci-intel-cnl 0000:00:1f.3: error: sof_probe_work failed err: -2

So, missing firmware, huh? I had though that mhwd should take care of that, but it seems I was wrong.

I installed the sof-firmware package, rebooted, and all is fine now.

The mystery that remains is of course how on earth that firmware went missing in the first place because I’m pretty sure I did not remove it explicitly, and I also would have expected it to be a dependency of something else on this system.

If someone has a good theory how a firmware module could go missing, I’m interested in hearing that, but otherwise things are working now.

1 Like

you can try toreverse it and switch back to pulseaudio as here:

otherwise this link might be helpful if you wanna check pipewire:

Thanks for the tip!

I switched back to Pulse, but I find that Pipewire gives me fewer confusing profile choices*, so that’s what I’m sticking with for now.

Happy to report that switching works fairly easily, by installing either manjaro-pulseaudio or manjaro-pipewire, although the first time switching to pipewire, I had to manually uninstall one of the pulseaudio packages because it was recognised as conflicting but not automatically replaced. It’s also interesting that uninstalling either pulseaudio or pipewire completely will take most of the system with it.

[*]: although they’re still pretty confusing compared to what they used to be not long ago. I’ve no idea why my choice of output profile with Pulse are four mildly different variations of “play Hifi quality music (HDMI1, HDMI2, HDMI3, Headset, Mic1, Speaker)”, instead of just a choice of possible output channels (“HDMI” or “Speaker”. And “Headphones” if they’re plugged in). Pipewire reduces that to two variations, at least. Okay, it gets really confusing in “pro” mode (which just gives me numbers with no informational content), but that’s for later.

please pay attention that hdmi has some traps with the cables. you have to make sure that the used hdmi-cable is wired to use special functions as “special”-hifi etc.. in a lot of cases a “cheap” cable causes the problems. hdmi is a perfect example about the problem of “standards” that no-one cares about.

sof-firmware does not depend on or require any other packages so it is unlikely to have been removed during an update

pacman log would confirm if package was removed:

grep 'sof-firmware' /var/log/pacman.log

Hif-Fi card profiles in pulseaudio or pipewire-pulse are provided by ALSA Use Case Manager alsa-ucm-conf

WirePlumber documentation - ALSA configuration - Device Proerties

The following properties can be configured on devices created by the monitor:

api.alsa.use-acp

Use the ACP (alsa card profile) code to manage this device. This will probe the device and configure the available profiles, ports and mixer settings. The code to do this is taken directly from PulseAudio and provides devices that look and feel exactly like the PulseAudio devices.

Default value: true
Type: boolean

api.alsa.use-ucm

When ACP is enabled and a UCM configuration is available for a device, by default it is used instead of the ACP profiles. This option allows you to disable this and use the ACP profiles instead.

This option does nothing if api.alsa.use-acp is set to false.

Default value: true
Type: boolean

ALSA Library documentation - ALSA Use Case Interface

Pro-Audio card profile is for using pipewire-jack instead of pipewire-pulse

Thanks!

Digging a little, I find it in the logs indeed, as being removed in october.

Digging further, I find the traces of me trying to wrestle Meshroom into submission, running into conflicts and uninstalling a whole host of unneeded stuff, especially things installed from AUR. And I remember how I chose what to remove, that is by listing all packages that are not dependencies of others, and removing most of the things I don’t recognise. Seems I went a bit overboard there.

It would be nice if some part of the system (KDE, Manjaro firmware etc) had been able and willing to bring this to my attention. One issue is that I’ve become conditioned to ignore all the warnings about “Possibly missing firmware” that show up whenever initcpio images are built after an update, and even if I wasn’t, xhci_pci is not something I that rings a bell for me.

Thanks for the help, again! At least I know now which mistake I made.

This might have to go into a different thread since it’s deviating from the original question, but I’m quite interested in figuring this out.

So … in which context am I able to change the configuration? I have a package names alsa-ucm-conf installed, which includes a veritable maze of configuration files. I found the phrase “play Hifi Quality Music” in the /usr/share/alsa/ucm2/Intel/SOF.SOF.conf, and quadupled the information density by changing it to “Hifi audio”. I’ll probably have to reboot to see if this had any effect – and beyond that, I have no idea how to achieve anything.

  • Most of the *.conf files look like I’d have to spend a day just to figure out what they’re meant to do, and I’m not even sure if it’s a wise idea to change them by hand, as there could be any number of gotchas attached to that approach
  • alsa-ucm-conf is not a valid command on my machine, so … is the Use Case Manager actually something I can invoke and configure, or just some automated process?
  • api.alsa.use-acp and api.alsa.use-ucm may be useful, except I don’t know what it does in practice, and I also don’t know from which context these …variables? flags? switches? attributes? are even accessible. Am I looking at Python syntax here? Would I need to write a Python script to manipulate these settings? Is there already one on my machine? If yes, where? Should I modify it (hopefully not!), or does it read the settings from an external configuration file, like a good script? If so, then where is that configuration file?

…you see, there is a lot of information missing here. And most of all: Is the behaviour that I’m trying to achieve even achievable?

I have a laptop at work which runs Kubuntu 22.04, and there I can set the audio output of the builtin audio device to go either to the headphone, the speakers or the HDMI port. Independent of that, I can select whether it should receive audio signals from the built-in microphone or from the headset (if one is plugged in). And I’m still confused as to why anyone thought that “play HIFI QUality Music” was an appropriate component for the label for any of those options, or why the input and output options should/could not be independent of each other. Which is to say: There may be a good reason, but from a user’s perspective it’s not at all visible.

Sound Open Firmware drivers are only needed to support built-in digital microphones on Intel laptops

If the built-in microphones are not needed, this command will load standard snd_hda_intel audio driver instead of sof-firmware driver

sudo tee /etc/modprobe.d/alsa-hda-intel.conf <<< "options snd_intel_dspcfg dsp_driver=1"

reboot system to reload ALSA and drivers

The use case manager can be disabled by creating a file in user home folder:
~/.config/wireplumber/wireplumber.conf.d/alsa-config.conf
and adding this:

monitor.alsa.rules = [
  {
    matches = [
      {
        device.name = "~alsa_card.*"
      }
    ]
    actions = {
      update-props = {
        api.alsa.use-ucm = false
      }
    }
  }
]

Migrating configuration from 0.4 — WirePlumber 0.5.12 documentation

reboot system or restart wireplumber service to load this rule

systemctl --user restart wireplumber 

Package alsa-utils includes alsaucm CLI utility to access ALSA Use Case Manager configuration

The eXtensible Host Controller Interface specification is more commonly known as the USB 3.0 host controller specification

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.