Lost Laptop Audio

Help
1

Dear all,

Ik have lost my adio output devices, Gnome just reports “Dummy output”, which even completely disappears upon a systemctl restart --user pipewire.service.

Here is some information:

● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/etc/systemd/user/pipewire.service; linked-runtime; preset: enabled)
    Drop-In: /nix/store/vdjv3wr2lyxq36wrdprzdw81r00cgh8s-user-units/pipewire.service.d
             └─overrides.conf
     Active: active (running) since Thu 2024-08-08 09:23:52 CEST; 2min 45s ago
TriggeredBy: ● pipewire.socket
   Main PID: 17430 (pipewire)
      Tasks: 4 (limit: 38037)
     Memory: 4.9M (peak: 5.4M)
        CPU: 34ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service
             └─17430 /nix/store/53y48491rwmjl7c2xiwa6b962j6lc14y-pipewire-1.0.7/bin/pipewire

aug 08 09:23:52 nixos systemd[2112]: Started PipeWire Multimedia Service.
aug 08 09:23:52 nixos pipewire[17430]: mod.jackdbus-detect: Failed to receive jackdbus reply: org.freedesktop.DBus.Error.ServiceUnknown: The name org.jackaudio.service was not provided by any .service files

And:

[freek@nixos:~]$ sudo dmesg | grep audio
[   19.538576] sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
[   19.538790] sof-audio-pci-intel-tgl 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
[   19.538808] sof-audio-pci-intel-tgl 0000:00:1f.3: enabling device (0000 -> 0002)
[   19.539464] sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
[   20.734192] sof-audio-pci-intel-tgl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[   20.759660] sof-audio-pci-intel-tgl 0000:00:1f.3: use msi interrupt mode
[   20.833471] sof-audio-pci-intel-tgl 0000:00:1f.3: hda codecs found, mask 5
[   20.833483] sof-audio-pci-intel-tgl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now
[   20.833492] sof-audio-pci-intel-tgl 0000:00:1f.3: DMICs detected in NHLT tables: 2
[   20.841941] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:2:0-57864
[   20.841951] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
[   20.841966] sof-audio-pci-intel-tgl 0000:00:1f.3: unknown sof_ext_man header type 3 size 0x30
[   20.956982] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:2:0-57864
[   20.956996] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
[   20.980321] sof-audio-pci-intel-tgl 0000:00:1f.3: Topology: ABI 3:22:1 Kernel ABI 3:23:0
[   20.980964] sof-audio-pci-intel-tgl 0000:00:1f.3: error: sink HDA6.OUT\xe7L\x89L$\x08\xe8 not found
[   20.981143] sof-audio-pci-intel-tgl 0000:00:1f.3: error: tplg component load failed -22
[   20.981153] sof-audio-pci-intel-tgl 0000:00:1f.3: error: failed to load DSP topology -22
[   20.981157] sof-audio-pci-intel-tgl 0000:00:1f.3: ASoC: error at snd_soc_component_probe on 0000:00:1f.3: -22

Any ideas? It has been working normally for 2 years now, this is my config:

  # Enable sound with pipewire.
  sound.enable = true;
  hardware.pulseaudio.enable = false;
  security.rtkit.enable = true;
  services.pipewire = {
    enable = true;
    alsa.enable = true;
    alsa.support32Bit = true;
    pulse.enable = true;
    # If you want to use JACK applications, uncomment this
    #jack.enable = true;

    # use the example session manager (no others are packaged yet so this is enabled by default,
    # no need to redefine it in your config for now)
    #media-session.enable = true;
  };

Attaching a USB headset does work as expected, so it is only the Laptop audio that has gone missing.

2

Is there an older generation with which the problem does not manifest?

3

Perhaps there is an entry in Grub indeed, but there is not another version of the configuration.nix because that has stayed the same over the last months.

Do you want me to check on earlier “checkpoints”, and run the same commands, would that help?

4

Whether the same commands or however way is most convenient to find out whether this problem exists. If you find an older generation in which this problem does not exist, then we’d have reason to believe this is caused by a change in nixpkgs.

5

Ok, thanx I will check some earlier versions later today and post here.

6

If it occurred after a NixOS-/kernel-update, it’s probably a (known) kernel-bug.

Workarounds: Use a different kernel or a kernel-patch, as described in:

2 Likes
7

This looks very similar indeed, looks like a fix is on its way, I’l sit this one out then, thanx!