PipeWire: Difference between revisions
From YM2149.org
Jump to navigationJump to search
(→Can we fix it: too distracting) |
No edit summary |
||
Line 37: | Line 37: | ||
== Use case == | == Use case == | ||
* fundamentally, i have the hardware and want to send audio to it without jumping through hoops such as lua | * fundamentally, on my server i have the hardware and want to send audio to it without jumping through hoops such as lua | ||
* one instance of mpd for builtin audio, running as a regular user, and it should continue to be audible after logout | * one instance of mpd for builtin audio, running as a regular user, and it should continue to be audible after logout | ||
** in the future another mpd for hdmi, and further instances for any usb audio adapters i might add | ** in the future another mpd for hdmi, and further instances for any usb audio adapters i might add | ||
== Just use ALSA == | === Just use ALSA === | ||
* <code>sudo systemctl --global disable</code> everything with pipewire or wireplumber in its name | * <code>sudo systemctl --global disable</code> everything with pipewire or wireplumber in its name |
Revision as of 20:57, 17 February 2025
- the latest framework that claims to 'fix' linux audio
- existing interfaces e.g. alsa, pulse, jack are emulated
- the idea is that existing tools/apps will 'just work' without modification
- fair in the case of a well-known browser that refuses to talk to anything but pulse
Problems
- in practice interface emulation is incomplete, so tools in particular are less capable than before
- this is inevitable, interfaces will only be as complete as what looks good, they will never be as powerful as the real thing
- all audio hardware is grabbed on startup denying anything else from using it directly
- furthermore, nothing works over ssh (or systemd linger) unless a real login session is open
- pipewire seems to be under the control of something called wireplumber, via a secret interface and with impenetrable configuration
- presumably this makes sense to certain individuals, but users want task-focused tooling
- specifically, don't force me to be a config expert before i can make changes
Parallels with PulseAudio
- deployed at the exclusion of legacy services when migration paths are missing
- obsession with the way things 'should' be done at the expense of use-cases of real users
- in particular, aggressive teardown of user services after logout
- criticism from real users rudely dismissed, for example https://linuxmusicians.com/viewtopic.php?t=24830
- the users are supposed to be in control, not the machine
- please do not force users to understand systemd, it is like unconsensually involving them in a kink
Can we fix it
- it is essential that users have the power to take matters into their own hands if necessary
- this is not a support burden, power users can support each other
- make common tasks easy and sophisticated tasks possible
- just playing sound is common, session management is sophisticated
- grab a subset of hardware based on config
- this can be a sensible default for users who don't know what hardware they have
Use case
- fundamentally, on my server i have the hardware and want to send audio to it without jumping through hoops such as lua
- one instance of mpd for builtin audio, running as a regular user, and it should continue to be audible after logout
- in the future another mpd for hdmi, and further instances for any usb audio adapters i might add
Just use ALSA
sudo systemctl --global disable
everything with pipewire or wireplumber in its name- this includes something called filter-chain
- check no such symlinks remain under
/etc/systemd
- reboot and verify nothing with wire in its name is running, both over ssh and when logged in properly
- add self to
audio
groupaplay -L
should work now- probably need to crank volume back up using alsamixer