PipeWire: Difference between revisions

From YM2149.org
Jump to navigationJump to search
No edit summary
No edit summary
 
(17 intermediate revisions by the same user not shown)
Line 12: Line 12:
** this is inevitable, interfaces will only be as complete as what looks good, they will never be as powerful as the real thing
** 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
* all audio hardware is grabbed on startup denying anything else from using it directly
* something called wireplumber controls pipewire via a secret interface
** furthermore, nothing works over ssh (or systemd linger) unless a real login session is open
** impenetrable configuration
* 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 ===
=== Parallels with PulseAudio ===


* deployed way before it's ready, which would be fine it that wasn't at the exclusion of legacy services
* 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
* 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
** in particular, aggressive teardown of user services after logout
* criticism from real users rudely dismissed, for example https://linuxmusicians.com/viewtopic.php?t=24830
* criticism from real users rudely dismissed, for example https://linuxmusicians.com/viewtopic.php?t=24830
** i cannot stress enough how icky it is to blame frustrated users for obtuse software, do better
** 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
* please do not force users to understand systemd, it is like unconsensually involving them in a kink


Line 28: Line 30:
* it is essential that users have the power to take matters into their own hands if necessary
* 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
** 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 ==
== 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, another for hdmi
* one instance of mpd for builtin audio, running as a regular user, and it should continue to be audible after logout
** usb audio adapters each with its own mpd planned for the future
** in the future another mpd for hdmi, and further instances for any usb audio adapters i might add
* mpd runs as a regular user, and every instance should continue to be audible after logout


== 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
** this includes something called filter-chain
** this includes something called filter-chain
** check no such symlinks remain under <code>/etc/systemd</code>
** check no such symlinks remain under <code>/etc/systemd</code>
** reboot and verify nothing with wire in its name is running
** reboot and verify nothing with wire in its name is running, both over ssh and when logged in properly
* add self to <code>audio</code> group
* add self to <code>audio</code> group
** <code>aplay -L</code> should work now
** <code>aplay -L</code> should work now
** probably need to crank volume back up using alsamixer
** probably need to crank volume back up using alsamixer


[[Category:Programming]]
[[Category:Computing]]
[[Category:Wisdom]]
[[Category:Wisdom]]

Latest revision as of 08:37, 23 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 group
    • aplay -L should work now
    • probably need to crank volume back up using alsamixer