You are not logged in.
Hey guys,
I'm beating my head against the wall here so I figured it's time to ask for help. I have a pretty basic Arch install, and at first I simply specified my default soundcard in my .asoundrc, set my volume using alsamixer, and thought I was good. Unfortunately I'm not.
I'm using hyprland and I've installed pipewire and wireplumber (as recommended) to enable screen sharing in Slack and other apps. What I noticed is that after each reboot, my master volume level gets reset to a pretty low setting (as seen in alsamixer). I narrowed this down a bit. If I set my volume in alsamixer in the TTY, reboot, the volume comes back as expected. If I start hyprland and run alsamixer in a terminal, the levels are different and the master volume is back to being low. If I then switch to another TTY console and open alsamixer, I see the same low levels I just saw in my running hyprland session.
So, it feels like hyprland is overriding the settings, but after some thinking and reading, I think it may be pipewire that's fighting with alsa?
What I don't understand is the following:
1. Since alsa is there by default, what should be done when one installs pipewire/wireplumber like I did? Should something be disabled? I read that maybe the alsa store/restore service needs to be disabled?
2. How do I set my default sound device? Via .asoundrc as I currently am, or via pipewire/wireplumber somehow?
3. How do I set my default volume level? I'm assuming this would have to be done via pipewire/wireplumber somehow?
4. Should I be doing something with pipewire/wireplumber that isn't done by default? Enable or disable a service?
5. Should I install any other pipewire packages, like pipewire-alsa or pipewire-pulse? I don't fully understand what decides to use alsa directly, or pulseaudio or pipewire. Is that something each app decides?
I think I'm just confused about the basics, but also would like to do things the right way and have them stick through reboots.
Last edited by Horghski (2025-01-14 16:14:17)
Offline
Which PipeWire packages are installed, exactly?
You probably need pipewire, pipewire-audio, pipewire-alsa, pipewire-pulseaudio & wireplumber as a minimum. Do you have all those?
For default output devices use either pactl(1), wpctl(1), or pw-cli(1). If you prefer a GUI pavucontrol should work.
ALSA is a kernel component and a set of associated libraries, PipeWire works on top of it rather than instead of it. Once PW is running ~/.asoundrc should have no effect.
Jin, Jîyan, Azadî
Offline
Neither alsa.store nor restore run by default anyway, but they shouldn't hurt when ran
via pipewire/pulse tools, see the reply above, you can set that with any of these tools, Get rid of the .asoundrc and install pipewire-alsa, if you ever run into something that actually requires ALSA configuring a .asoundrc incorrectly will not give you output out of that application.
with the tools listed and mentioned above volumes should get restored to what you last set them to via pactl/wpctl, wireplumber stores the volumes you've set in it's context and should reapply them, occasionally certain audio chips have some bugs here, but let's check once you've actually set those
They should be enabled by default assuming you have a proper session, check
systemctl --user status pipewire{,-pulse} wireplumberyes you want both of them. And yes each application decides which API to use, the vast majority will use pulseaudio, that's been the primary API on linux for the last few years, ALSA-only is really only done by a few legacy applications, or audio production focused ones (those might opt for JACK even, but pipewire can cover that as well)
The different APIs and why and how they exist has mostly historical reasoning and context that would probably be out of scope to explain here. But ultimately pipewire has been designed to combine them under one somewhat consistently working umbrella and is probably the most actively developed of the sound daemons and also has commercial backing by having a few full time devs employed by Red Hat.
Offline
I really appreciate the replies! So, to start, this is what I have installed sound-related:
local/libpipewire
local/libwireplumber
local/pipewire
local/pipewire-audio
local/pipewire-jack
local/pipewire-session-manager
local/wireplumberI didn't actually install any of those manually, I think pipewire was installed as a dependency of xdg-desktop-portal-hyprland.
This is the output of the systemctl command you asked for
? systemctl --user status pipewire{,-pulse} wireplumber
Unit pipewire-pulse.service could not be found.
● pipewire.service - PipeWire Multimedia Service
Loaded: loaded (/usr/lib/systemd/user/pipewire.service; disabled; preset: enabled)
Active: active (running) since Tue 2025-01-14 07:55:18 CST; 14min ago
Invocation: 7992d39bec1248e2932e4405ee4ab051
TriggeredBy: ● pipewire.socket
Main PID: 1033 (pipewire)
Tasks: 3 (limit: 38117)
Memory: 6.3M (peak: 7.9M)
CPU: 967ms
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service
└─1033 /usr/bin/pipewire
Jan 14 07:55:18 trogdor systemd[650]: Started PipeWire Multimedia Service.
● wireplumber.service - Multimedia Service Session Manager
Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; preset: enabled)
Active: active (running) since Tue 2025-01-14 07:55:18 CST; 14min ago
Invocation: 2fbb8babb826431fa07801692294a5bd
Main PID: 1034 (wireplumber)
Tasks: 6 (limit: 38117)
Memory: 11.1M (peak: 13.1M)
CPU: 177ms
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/wireplumber.service
└─1034 /usr/bin/wireplumberSo, if I'm reading that correctly, the pipewire service is disabled on boot, but currently active (running). I don't recall disabling it manually. Should I enable it at boot?
I also don't have pipewire-pulse, but I can install it.
So I removed my .asoundrc and rebooted and surprisingly, my audio device was selected correctly when I tested sound with a browser (I verified via wpctl status). Not sure if that will stick as I'm still not sure how to set a default device using wpctl. I've been reading the WirePlumber Wiki and set my sound via
wpctl set-volume @DEFAULT_AUDIO_SINK@ 1.0which appears to have worked. However, is WirePlumber smart enough to select that device as default from now on?
I know my device IDs have changed over reboots before, that's what got me looking into this as suddenly my .asoundrc was referring to the wrong device. From the reading I've done, I think I can
1. Disable the "other" devices via a conf file in ~/.config/wireplumber/wireplumber.conf.d
2. Or, set the priority of my desired device higher, again in a WirePlumber conf
Are either of those recommended or necessary? If so, is there a preference as to which?
Edit: I just used wpctl to inspect my two devices, and the device I want currently has a higher priority number. Can I then assume that it will always be selected as a default device? I'm not sure why it wasn't before, maybe the .asoundrc was screwing with it.
Thanks!
Last edited by Horghski (2025-01-14 14:29:05)
Offline
"device indices" can change from boot to boot, if your .asoundrc tried to reference the "default" device via hw:0 or so, that 0 can change depending on which device the kernel enumerates first. wireplumber/pipewire use more guaranteed identifiers like pci bus as well as the "name" property of ALSA which is more guaranteed to be unique and not change depending on detection order.
pipewire/wireplumber (actually: pulseaudio where most of this originated from) have the concept of device profiles you can configure and there you can also disable a device, you can do that directly with pavucontrol/wpctl and that will stick without you doing a specific custom configuration yourself.
the default device can also be explicitly set with
wpctl set-default $idand that will be the default (for newly started audio, technically you can have wireplumber remember if you had specific audio on a different device than the default and so forth)
Assuming you want your audio via wireplumber/pipewire now, I'd strongly suggest you install pipewire-pulse and pipewire-alsa as well.
One thing of note if you're using wireplumber now, you're strongly suggested to use tools for volume handling that directly manipulate wireplumber state a, like wpctl, or if you opt for pulse mixers, pactl or pavucontrol or so (I'd suggest you install pavucontrol it gives you a relatively intuitive interface for how the interaction between audio cards (sinks) and audio clients (sink-inputs) work) instead of alsamixer, otherwise you'll end up in a logical conoundrum again since wireplumber will not be aware of manipulations you're doing via alsamixer.
Last edited by V1del (2025-01-14 14:46:31)
Offline
That's really helpful, thank you again. I installed pipewire-pulse and pipewire-alsa. I see that both pipewire and pipewire-pulse services aren't enabled on boot, so I assume they get triggered by clients like xdg-desktop-portal when they're needed (as both are active now). I uninstalled alsa-utils and I'll be sticking to using wpctl, it seems easy and flexible enough. I can also use it in key bindings in hyprland if needed be to control the volume.
I'll check out pavucontrol, I see there is also pwvucontrol in the AUR. As far as I understand it now, pipewire uses the same APIs as pulse, so in theory both GUIs work the same way?
I'll update the post to solved, but if I run into any other issues I'll bump it.
Thanks!
Offline
Pretty much, whether you use a pipewire API or pulse based mixer implementation pipewire will generally be aware of which manipulations are being done and can persist them accordingly via it's own abstraction layers.
Technically the pipewire API doesn't exactly map to pulseaudio and vice versa, but internally pipewire knows how to handle both kind of requests and the difference only becomes relevant in very specalized usecases.
I'd personally not necessarily uninstall alsa-utils as they can be helpful when something lower level breaks (e.g. kernel bugs changing HW behaviour and pipewire not properly accounting for it, alsa-utils allows a more direct look at what's happening on a lower level in that regard)
Offline