#pulseaudio

[verilog-official]

question to linux users

what sound server do you (primarily) use?

pipewire

pulseaudio

alsa

jack

oss/other

Voting ended onFeb 22, 2025

[andmaybegayer]

Should I be using pipewire over pulseaudio and if so why?

If you're on Wayland you should definitely at least check out Pipewire, because Pipewire and Wayland both follow a similar philosophy and are kind of being developed side by side. Pipewire with portals is one of the ways to do screen captures and screenshots on Wayland.

If you're running Flatpaks then Pipewire's integration with Flatpak Portals and xdg-desktop-portals more generally will simplify media handling for Flatpaks and generally make running Flatpak media applications more reliable and seamless.

If you use Bluetooth audio, Pipewire has simpler first class support for a wider array of Bluetooth codecs (high bitrate SBC/AptX/LDAC/AAC) and generally simplifies the process of setting up Bluetooth devices exactly the way you want over Pulse.

If you currently fight with running Jack sometimes (or worse, simultaneously running Jack and Pulseaudio) then you should definitely check out Pipewire, because Pipewire implements both Pulse and Jack compatibility layers that are way easier to look after and which can run simultaneously without any fuss.

If you're doing music production with Pulse, Pipewire's pro audio mode might give you some small quality of life improvements by reducing latency and improving inter-program audio links.

If you're doing a lot of live video stuff, especially video involving desktop capture on Wayland, Pipewire can simplify shuttling video around because in addition to handling audio, it handles arbitrary media streams, but you might have this worked out however you're already doing it.

If you are just running a standard X11 desktop and have no problems using Pulseaudio right now, you probably won't notice any change if you switch to Pipewire, especially if you aren't running Flatpaks or Bluetooth. Since Pipewire currently implements a lot of stuff through a Pulseaudio compatible interface, your normal actions with pactl and pavucontrol will continue working transparently or with minimal changes if you do switch.

Installing Pipewire is relatively easy if you don't have any custom pulse configuration. You just have to remove Pulse and install the pipewire, pipewire-alsa and pipewire-pulse packages.

[neverprogrammingagain]

Hello, this is Linus Torvalds, and I pronounce PulseAudio as Pu.psh.sAddia...u..psh

https://wiki.archlinux.org/index.php/PulseAudio/Examples

(via nixCraft‏)

[pratsdigital]

PipeWire vs PulseAudio: Which Audio Server is Better for Linux in 2025?

If you’ve been using Linux for a while, you’ve probably heard about PipeWire replacing PulseAudio in many distributions.But what exactly are these two? And is PipeWire really better? Let’s break it all down in simple terms. Quick Answer PipeWire is the modern replacement for PulseAudio, offering better performance, lower latency, and improved support for both audio and video streams.While…

PipeWire vs PulseAudio: Which Audio Server is Better for Linux in 2025?

[nazionlinux]

Pipewire su Voidlinux

Pipewire è un server moderno per gestire i flussi audio e video su Linux e si può interfacciare con ALSA, PulseAudio ed il sistema Jack audio. Per far funzionare Pipewire è richiesta una sessione D-Bus attiva oppure se non si usa un ambiente grafico può essere lanciato tramite dbus-run-session. Inoltre va definita la variabile di ambiente XDG_RUNTIME_DIR per funzionare…

View On WordPress

[tom2tec]

Pipewire ~ Linus Audio Processing

PipeWire is a project that aims to greatly improve handling of audio and video under Linux. It provides a low-latency, graph-based processing engine on top of audio and video devices that can be used to support the use cases currently handled by both PulseAudio and JACK. PipeWire was designed with a powerful security model that makes interacting with audio and video devices from containerized…

View On WordPress

[stevensaus]

Two Ways To Access A Remote PulseAudio Session Over SSH

Despite what you may read elsewhere, there are two ways to control the volume on a remote machine running PulseAudio when you can only access it via SSH. I am not talking about using X forwarding here (which does NOT work), and I do not mean running a whole remote desktop session via VNC or X2Go just to mess with the volume. Nor do you need to run PulseAudio as a system service, or edit PulseAudio's configuration files at all. This is done using command line tools only. Specifically, tmux, pulsemixer, and volumerb. This works on a fresh install of Debian bookworm, where I have not altered any PulseAudio configuration files at all. The system in question has audio two devices - a "regular" audio output and a HDMI output. The Problem Because of some very good complicated security reason , unless you are running a system-wide configuration of PulseAudio (which is not a great idea ), you typically cannot connect to an already running PulseAudio daemon when you SSH into a system. When would this come up? In my particular case so that I can adjust the volume on my media center PC from my laptop with a few simple scripts. It's definitely one of those things not everyone will need, but when you do need it, you need it. The Solution For this, I've done the following (the PulseAudio setup is the default that Debian configured, and works perfectly fine locally): - sudo apt install tmux pulsemixer ruby - wget https://raw.githubusercontent.com/uriel1998/volumerb/master/volume.rb - sudo mv ./volume.rb /usr/local/bin/volume - sudo chmod +x /usr/local/bin/volume - Create a tmux session, have at least one open shell window in that session, and detach from it on the machine whose volume you want to control. Not "connected via SSH", but actually on that machine. The tmux portions are actually extra, but they give you a lot more flexibility. And if you're regularly using SSH and don't know about tmux, you'll be doing yourself a lot of favors by knowing even a little about it. pulsemixer is a fantastic TUI program for handling PulseAudio, and I thoroughly recommend it.

But, as you can see in the first video below, if I just SSH in, pulsemixer returns Failed to connect to pulseaudio. That's also what happens if you try X-forwarding, by the way. However, you can see that - for reasons I do not understand - the volumerb script works out of the box. That script is comparatively klunky compared to pulsemixer, but for some reason it works. The only change from that script's normal behavior is that it only seems to work on whichever sink is set as the "default" sink, not all of the sinks. The interesting part comes next in this second video. You have a tmux session still running on the machine that you just SSH'd into. You can attach to that existing session (tmux attach), and in any windows that were created on the local machine, you can use pulsemixer normally. It attaches to the running PulseAudio session with no difficulty. But again, this workaround only works with windows (and sessions) that were originally created locally. In the video you can see that I create - connected over SSH - a new window. In that new window, I once again cannot connect to the PulseAudio session. But as before, volume.rb still works. So there you go - two ways to control PulseAudio on a remote machine via SSH without running PulseAudio as a system service. I do not understand the specifics of it, nor do I understand it well enough to explain it, but just enough to take seriously the warnings that it is a Very Good Idea to not work around the security here. Featured Image by Gerd Altmann from Pixabay Read the full article

[tilos-tagebuch]

Linux-Größe Lennart Poettering wechselt von Red Hat zu Microsoft

Der systemd-Erfinder Lennart Poettering verlässt den Linuxdistributor Red Hat und wechselt wohl zu Microsoft. Für WSL lässt das große Fortschritte erwarten.

Für Microsoft wäre Poettering sicherlich ein Gewinn. Das Unternehmen stellt mit WSL erste Unterstützung für Linux-Software bereit. Jedoch ist das Projekt noch nicht sonderlich weit fortgeschritten und hat mit vielen Einschränkungen zu kämpfen. So muss etwa ein Nutzer angemeldet sein, um Software im WSL laufen zu lassen – für Dienste eher suboptimal. Hier könnte Poettering sein Know-how einbringen und die Entwicklung zu einem vollwertigen, eigenständigen Subsystem vorantreiben. Poettering hat mit seinen Projekten wie PulseAudio und systemd erheblich zur Modernisierung von Linux-Systemen beigetragen, ist aber gerade unter Linux-Traditionalisten umstritten.