I’ve been trying for a while now but can’t for the life of me get sound to work, neither via PulseAudio, nor PipeWire. Here are the facts:
- Fresh install
- Laptop is ThinkPad P15s Gen 2
- My latest nix config (just the latest iteration. Tried all kinds of stuff)
journalctl output looking for pipewire
lspci -v output, including audio device
- Sound buttons don’t work and sound icon on tray (KDE Plasma) says “No output of input devices found”
It’s been suggested to me that I might be missing a device driver or something? Please help me troubleshoot, I’m really not sure how to check for that sort of thing.
I’m so frustrated . Ideally, I’d like to get Pipewire to work because I know it’s the more modern of the two, but I’d take anything at this point.
Happy to provide any additional info from my machine as needed.
I have the same laptop and the sound works (via pipewire). See Domen Kožar for details
Thanks. Good to know it’s compatible. Any ideas why mine might not be working?
@domenkozar Can you advise, I got the recommendation here from someone who had a similar issue, to install sof-firmware. What do you think of this? If so, how would I do this is Nix?
hardware.enableAllFirmware = true; and reboot.
I’m doing it right now. Rebuilding gets me this note:
[root@nixos:~]# nixos-rebuild switch
building the system configuration...
- the list of hardware.enableAllFirmware contains non-redistributable licensed firmware files.
This requires nixpkgs.config.allowUnfree to be true.
An alternative is to use the hardware.enableRedistributableFirmware option.
(use '--show-trace' to show detailed location information)
I believe I just need to add the line
nixpkgs.config.allowUnfree = true; in there as well?
@domenkozar Good suggestion but unfortunately no dice Anything else I can try?
Although, check this out. Taking another look at my journalctl output, it does look a little better now?
[root@nixos:~]# journalctl --user-unit=pipewire --user-unit=pipewire-media-session --user-unit=pipewire-pulse -f
-- Journal begins at Sun 2021-06-20 12:55:34 UTC. --
Aug 07 18:27:37 nixos systemd: pipewire.service: Current command vanished from the unit file, execution of the command list won't be resumed.
-- Boot 2a11bf650e2041d4b982a16f9922a576 --
Aug 07 21:07:09 nixos systemd: Started Multimedia Service.
Aug 07 21:07:09 nixos systemd: Started Multimedia Service Session Manager.
Aug 07 21:07:09 nixos pipewire-media-session: GetManagedObjects() failed: org.freedesktop.DBus.Error.ServiceUnknown
Aug 09 09:03:43 nixos systemd: Stopping Multimedia Service Session Manager...
Aug 09 09:03:43 nixos systemd: pipewire-media-session.service: Succeeded.
Aug 09 09:03:43 nixos systemd: Stopped Multimedia Service Session Manager.
Aug 09 09:03:43 nixos systemd: Stopping Multimedia Service...
Aug 09 09:03:43 nixos systemd: pipewire.service: Succeeded.
Aug 09 09:03:43 nixos systemd: Stopped Multimedia Service.
I don’t believe I was seeing
pipewire.service: Succeeded. before. Progress?
Can you post
journalctl -t kernel -b
Yep absolutely @domenkozar , thank you. Output here.
The kernel log doesn’t look complete.
It seems that the AMD version of the laptop I have has a different sound card, so we can’t really compare.
I’d look into what kernel modules you might want to load, it’s entirely possible NixOS doesn’t enable that driver.
For example Intel Tiger Lake-LP Smart Sound Technology Audio Controller
sorry, you’re correct. Here’s the full output. Ok yes, thank you, I’ll look into what other modules I should load.
uname -r on my machine shows me I’m running kernel version
5.12.10. From your linux-hardware.org link, does that mean I need that Ver: 5.12 - 5.13 row from the Kernel Drivers rubrik?
- How do I check if this is already installed, so I’m not duplicating or overwriting anything unnecessarily?
- Can you please advise how to actually install it?
Unrelated to your hardware questions, but have you tried running this as a non-root user? Pipewire uses the user dbus instance, and I believe I’ve run into situations where that wasn’t launched for the root user before.
Your kernel log shows it detecting the device with the linked driver (grep for
audio to see all related things), so I believe kernel wise everything should be fine.
I’d also suggest looking at the raw output of
dmesg, it’ll list any hardware startup oddities in red, so it’s hard to miss severe issues if this is indeed a hardware problem.
And while you’re at it, try
journalctl -xe --user --unit pipewire - it’ll show us if the unit keeps restarting due to some error, instead of just the last few log lines
@TLATER Thank you so much for reaching out! Truly appreciate it. I’m going to try all of that right after work. No I haven’t tried with non root. I’ll need to create a user for myself. Oh boy… if this was all because something wasn’t working for me as root that would as a regular user that would be weird.
Will get back to you asap
@TLATER from their post "[solved] updated some systemd units to remove =!root"
How would you do this in nixos?
I wouldn’t do that to begin with, on any distro There are reasons why these things are disabled for specific users. That said, I don’t actually know what that post is referring to, there is no such option I’m aware of.
Mind telling us more about your scenario? Why are you running as root? This is generally a symptom of some wider issues, which you should definitely solve; running normal applications (that would produce sound) as root is usually a bad idea.
Oh that’s pretty straightforward. At the very beginning, I had a whole other MESS of troubleshooting I needed to do for something else, and was again stuck for a long while. I was logged in as a regular user and someone pointed out that there is a difference between running admin commands via sudo vs running them actually assuming the root user. So then I switched to root and have been using that account since.
Going to try as a regular user asap and report back, along with the other material you asked about.
I was logged in as a regular user and someone pointed out that there is a difference between running admin commands via sudo vs running them actually assuming the root user.
For reference, this is true, but for the most part not really significant. The difference is that typically
sudo carries over some user environment variables to ensure you don’t get too many surprises, specifically I think
$HOME isn’t set to
What may confuse some users as well is that only the command executed is executed as root - i.e., file descriptors provided by bash and piped-to commands are still executed as your user. I.e., this will likely fail because bash (executed by your user) tries to open
/root/hello - though some may believe them all to be the same “command”:
sudo echo 'Hello' > /root/hello
Most everything else should be the same.
If you’re sure you’d actually like to temporarily become the root user for some reason, use
sudo -s instead. This is useful sometimes, mostly when you want to pipe to a file like above or when you visit some root-owned directories.
You should basically never run actual desktop applications (let alone log into a desktop) as root - if anything requires enhanced privileges, it will ask you for such via polkit and a graphical pop-up. If it doesn’t, something else is going wrong