18 ms·

PipeWire: The Linux audio/video bus

457 points by darwi 6y ago

deleted 6y ago
[deleted]
xorcist 6y ago
What does real world latency look like with Pipewire? Is it comparable to jackd when used with something like Ardour?
- dralley 6y ago
  The FAQ provides some great information - no hard numbers though https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#dont-pro-audio-and-consumer-audio-have-conflicting-requirements https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ... https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#is-pipewire-another-jack-implementation https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ... https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#will-pipewire-ever-be-as-good-as-jack https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...
- cptn_brittish 6y ago
  It has a jack and pulseaudio api wrapper. I use it because it means I don't need to muck around with configuring pulse and jack to work nicely together.
- fmoralesc 6y ago
  Just tried recording from my laptop's mic - the reported latency from Ardour was 5,3ms (with 256 samples/buffer). It crashed when I went down to 128 samples/buffer.
nitsky 6y ago
PipeWire has worked very well for me both as a drop-in replacement for PulseAudio and to enable screen sharing on Wayland.
- ledbettj 6y ago
  It also worked as drop in replacement for PulseAudio for me, except all my audio now had stutters and pops. I ended up going back to Pulse. I got suggestions that I could go tweak buffer sizes stuff in a config file somewhere, but for my simple desktop use case I'd rather my audio just sounds right out of the box. Hopefully this sort of thing gets straightened out, because having to muck with config files to make my sound server actually work is like going back to working directly with ALSA or OSS.
  - pkulak 6y ago
    I had a couple little issues as well when I switched over a couple months ago, but they just fell away over the ensuing weeks of updates until there's nothing left at the moment. Give it another try sometime soon.
    - cptn_brittish 6y ago
      I can confirm that a issue causing my audio to completely drop at random points resolved about 1 month ago and now everything works perfectly.
  - andrewzah 6y ago
    FWIW I had issues with it on debian 10, until I built and installed it from master. It was a bit smoother on debian 11 but I couldn't get bluetooth to work.
dbrgn 6y ago
The fact that PipeWire has the potential to replace both PulseAudio (for consumer audio) and Jack (for pro audio) with a unified solution is very exciting.
- bluGill 6y ago
  Particularly if you are on the pro audio side. Consumer audio can ignore pro-audio for the most part. However everyone on pro-audio needs to do something consumer audio once in a while, if only to run a web browser.
  - dbrgn 6y ago
    Exactly. If you're working on a project in Ardour and want to quickly watch a video on YouTube, stopping Jack and starting PulseAudio was a bit of a pain the last time I did that. Yes, you can configure PulseAudio as a Jack client, but the session handling is also a bit messy. (I used to have a PA -> Jack setup on my work computer just so I could use the Calf equalizer / compressor plugins for listening to music. I dropped it again after a while, because session handling and restoring wasn't always working properly. But that was around 6-7 years ago, maybe it would work better nowadays.)
  - warmwaffles 6y ago
    What is pro audio? I'm naive when it comes to this.
    - dbrgn 6y ago
      Setups for professional music production. This usually requires JACK (https://jackaudio.org/ https://jackaudio.org/) as audio server, which allows synchronizing and connecting multiple applications. For example, you can have Ardour (https://ardour.org/ https://ardour.org/) as DAW, but use another application like Hydrogen (http://hydrogen-music.org/ http://hydrogen-music.org/) for creating drum samples. JACK connects the two applications using a virtual patchbay that allows using Hydrogen as an Input for Ardour. Essentially any application can be an input and/or an output. JACK also provides synchronization using a "master clock", so that Hydrogen starts playing as soon as you hit the "record" button in Ardour. Many people also use a Linux kernel optimized for low latency audio. With PulseAudio, these things are not possible. On the other hand, consumer applications like web browsers don't usually offer direct JACK support. So bridging is necessary, by using PulseAudio as a JACK input.
pta2002 6y ago
Just tried it on NixOS, had no idea it was so fleshed out already! Thought it'd be full of bugs but was pleasantly surprised, it just worked. No issues with compatibility, extremely low latency and has JACK and PulseAudio shims, so everything works out of the box, including pro audio stuff like Reaper and Ardour. And thanks to the JACK shim I can patch around the outputs with qjackctl. This is compared to JACK, which I never managed to properly combine with PulseAudio.
- simias 6y ago
  But does it work with the OSS shim for alsa shim for pulseaudio shim for jack shim for pipewire? Jokes aside my first reaction upon hearing about pipewire was "oh no, not yet an other Linux audio API" but maybe a miracle will happen and it'll be the Chosen One. I know that audio is hard but man the situation on Linux is such a terrible mess, not in small part because everybody reinvents the wheel instead of fixing the existing solutions. Jack is definitely the sanest of them all in my experience (haven't played with pipewire) but it's also not the most widely supported so I often run into frustrating issues with the compatibility layers.
  - SilverRed 6y ago
    > not in small part because everybody reinvents the wheel instead of fixing the existing solutions. I'm using all of these reinventions. Wayland, systemd, flatpak, btrfs and soon pipewire. I'm absolutely loving linux right now. Everything works so nice in a way it will never on a distro with legacy tools. Some of these projects like flatpak have a few rough edges but the future is very bright for them and most problems seem very short term rather than architectural.
  - bisby 6y ago
    I also liked JACK the best. But was frustrated with compatibility layers. Pipewire lets me use all the JACK tooling, but without needing a special compat layer to manage it. so for now, I'm pretty excited Still havent figured out how to get anything working for video.
- kevincox 6y ago
londons_explore 6y ago
Without audio buffer rewinding, you're going to have to suffer random stutters and jumpiness every time your system comes under heavy load. Your system does an NMI because you plugged the power cable in? Your audio will glitch. It will also mean you won't be able to sit with an idle CPU while playing music - the audio daemon will have to wake up to reload buffers multiple times per second, killing battery life unacceptably for playing audiobooks on a phone... Saying rewindable audio is a non-feature might simplify the codebase, but if it makes it work badly for most use cases, it ought to be rethought.
- freeqaz 6y ago
  I'm not sure I understand this. Why can't you just increase buffer sizes and write more data to them to avoid frequency of wake ups? Edit: does this help? https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#pipewire-buffering-explained https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...
  - phkahler 6y ago
    Low latency is a goal. From video conferencing to music recording it's very important.
    - robert_foss 6y ago
      I think supporting the low latency usecase is a goal, but not the only one. As far as I understand it pipewire provides configurable latency.
    - jjoonathan 6y ago
      Eh, just process all audio in a once-a-day batch job at 2am, it'll be great!
    - jancsika 6y ago
      Except that professional music recording is a domain in which low latency always trumps power consumption. So if a system based on such a tradeoff fails even once due to complexity of buffer rewinding or whatever, the professional musician loses. Hell, Jack could be re-implemented as power-hungry, ridiculous blockchain tech and if it resulted in round-trip latency / 2 professional musicians would still use it. Edit: added "complexity of" for clarification
nialv7 6y ago
pipewire already works surprisingly well. Even bluetooth source and sink works. Only problems I had so far are: * sometimes bluetooth devices would connect but not output audio, have to restart pipewire. * sometimes pipewire gets confusing and doesn't assign audio outputs properly. (shows up in pavucontrol as "Unknown output")
chenxiaolong 6y ago
I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync. * DMA-BUF based screen recording works with OBS + obs-xdg-portal + pipewire (for 60fps game capture). For my use cases, the only things still missing are automatic switching between A2DP and HFP bluetooth profiles and support for AVRCP absolute volume (so that the OS changes the headset's hardware volume instead of having a separate software volume).
- foobarbecue 6y ago
  Did you get 2—way (in & out) 16khz Bluetooth to work? Am I right that this isn't possible?
  - chenxiaolong 6y ago
    I believe when the HFP profile is used and mSBC is supported, then mSBC is used for both the input and output.
- Abishek_Muthian 6y ago
  Would there be improvements for remote audio streaming over pulseaudio with ssh?
  - chenxiaolong 6y ago
    I'm not sure about this one. I haven't tried streaming audio over the network with either pulseaudio or pipewire.
- JeremyNT 6y ago
  If you use Arch Linux, it's really easy to just drop this right in from official packages as a replacement for Pulse/ALSA [0] and start using it. I've been running it for about a month and everything seems to work exactly as I expect it to. I honestly notice no difference other than the pulse audio input/output picker extension I had been using seems confused now (the native GNOME sound control panel applet works just fine though). On the video front I use obs-xdg-portal for Wayland screen capture as well - finally there's a good story for doing this! You even get a nifty permission dialogue in GNOME. You have to launch OBS in forced wayland mode with 'QT_QPA_PLATFORM=wayland obs' [0] https://wiki.archlinux.org/index.php/Pipewire#Audio https://wiki.archlinux.org/index.php/Pipewire#Audio
superluserdo 6y ago
Does anyone know if pipewire has its own audio protocol for applications, as well as taking the place of JACK and Pulse? Or will future applications still just decide whether to talk to "JACK" or "Pulseaudio"? (Both actually being pipewire)
- bitbang 6y ago
  It does. The support for Pulse and JACK APIs is to ease adoption.
OJFord 6y ago
It's great to see pipewire coming along, pulseaudio development seems to (to a spectator) to have been a little.. well.. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/227#note_712800 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge... https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/288#note_713222 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...
- entropie 6y ago
  This is so sad. I had no idea.
- uluyol 6y ago
  Isn't this probably because most developers have shifted focus on PipeWire? I thought both came from more-or-less the same community?
- dralley 6y ago
  While that seems like a huge cluster, it does kind of seem that the patch rejections come from a set of principles. If the patches would improve Bluetooth audio at the expense of breaking existing features, saying "we don't break existing features" is a valid position to hold.
  - rcxdude 6y ago
    I don't think the issue was breaking existing features, it was a classic 'perfect being the enemy of good' situation. PA maintainers wanted to support dynamically loading the involved codecs due to potential (but not particularly well demonstrated) concerns about licensing and inclusion in certain distros. But they didn't really have the manpower to actually do this (and especially they disagreed with the person actually doing the work on how to go about doing this), so they just sat on an MR for ages while the situation improved for no-one (worst case it gets merged and then disabled at compile time by some distros). Meanwhile frustrations arose because the contributer wanted to help users and the maintainers just seemed like a roadblock to doing this, and the maintainers utterly failed to de-escalate the situation.
- 6y ago
onli 6y ago
> including the raw Linux ALSA sound API, which typically allows only one application to access the sound card. If the raw in that sentence is not meant as a special qualifier and this is meant as a statement about ALSA in general, this is wrong. I recently read up on this to confirm my memory was right when reading a similar statement. In fact, ALSA had just a very short period where typically only one application accessed the sound card. After that, dmix was enabled by default. Supporting multiple applications was actually the big advantage of ALSA compared to OSS, which at the time really did support only one application per soundcard (without hardware mixing, which broke away at that time). I'm not sure why this seems to be remembered so wrongly? > Speaking of transitions, Fedora 8's own switch to PulseAudio in late 2007 was not a smooth one. Longtime Linux users still remember having the daemon branded as the software that will break your audio. This wasn't just a Fedora problem. Ubuntu when making the switch also broke Audio on countless of systems. I was active as supporter in a Ubuntu support forum at that time and we got flooded with help requests. My very own system did not work with Pulseaudio when I tried to switch, that was years later. I still use only ALSA because of that experience. At that time Pulseaudio was garbage, it should never have been used then. It only got acceptable later - but still has bugs and issues. That said, PipeWire has a better vibe than Pulseaudio did. It intends to replace a system that never worked flawlessly, seems to focus on compatibility, and the apparent endorsement from the JACK-developers also does not hurt. User reports I have seen so far have been positive, though I'm not deep into support forums anymore. Maybe this can at least replace Pulseaudio, that would be a win. I'm cautiously optimistic about this one.
- jcastro 6y ago
  > I'm not sure why this seems to be remembered so wrongly? It didn't work reliably on all chipsets/soundcards.
  - onli 6y ago
    I don't remember this at all, but this might explain that. Or maybe a distribution like debian stable shipped with an outdated ALSA version, taken from the short period between release and dmix. Or just disabled dmix. Would love if someone remembered specifics. I kinda assumed people mix up Alsa and OSS or don't remember anymore what actually did and what did not work before Pulseaudio was introduced.
gmueckl 6y ago
Nah, another audio daemon is not what Linux needs IMO. This should be merged into the kernel, especially since process isolation is one of the stated goals. Running hard realtime stuff in a user space that is designed to not provide useful guarantees related to hard deadlines is brave, but ultimately somewhat foolish. I know that there are arguments against having high quality audio rate resampling inside the kernel that are routinely brought up to block any kind of useful sound mixing and routing inside the kernel. But I think that all necessary resampling can easily be provided as part of the user space API wrapper that hands buffers off to the kernel. And the mixing can be handled in integer maths, including some postprocessing. Device specific corrections (e.g. output volume dependent equalization) can also fit into the kernel audio subsystem if so desired. AFAIK, Windows runs part of the Audio subsystem outside the kernel, but these processes get special treatment by the scheduler to meet deadlines. And the system is built in a way that applications have no way to touch these implementation details. On Linux, the first thing audio daemons do is break the kernel provided interface and forcing applications to become aware of yet another audio API that may or may not be present. This is just my general opinion on how the design of the Linux audio system is lacking. I am aware that it's probably not a terribly popular opinion. No need to hate me for it. [End of rambling.]
- tinco 6y ago
  I only read this article, so I'm still fuzzy on the exact technical details, but couldn't a system like pipewire eventually be adopted into the kernel after it has proven itself adequate? Or is that not a thing the kernel does?
  - bitbang 6y ago
    Probably not. Kernel handles the hardware. User-space deals with things like routing, mixing, resampling, fx, etc. Having that functionality outside of the kernel offers a lot more flexibility. Despite people chafing at the user-space audio API churn, it does allow advancements that would be much more difficult to do if implemented in the kernel.
- regularfry 6y ago
  Crossing the streams a bit, I'm wondering if there's enough grunt in EBPF to do mixing and resampling.
sp1rit 6y ago
I'm currently trying pipewire on openSUSE Tumbleweed. I'm very impressed with it so far. (After realizing it was broken, because I didn't have the pipewire-alsa package installed => No audio devices) The pulse drop-in worked flawlessly out of the box. I'd had some isssues with the jack drop-in libraries tho. (metalic voice, basically not useable) To fix this, I had to change the sample rate in /etc/pipewire/pipewire.cfg from the default 48000 to 44100.
- Arnavion 6y ago
  Have you been using some GUI to be able to control volume, etc? I've been holding out on replacing PA with PW on Tumbleweed until [1] is resolved so I can continue using pavucontrol (pavucontrol's deps will be satisfied by pipewire-pulseaudio and not only pulseaudio), which is currently blocked at [2] being accepted. Probably another week or so. [1]: https://bugzilla.opensuse.org/show_bug.cgi?id=1182730 https://bugzilla.opensuse.org/show_bug.cgi?id=1182730 [2]: https://build.opensuse.org/request/show/875208 https://build.opensuse.org/request/show/875208
alvatar 6y ago
I hope this fixes my issues with bluetooth on Linux. When I'm on battery the audio breaks all the time. I've tried all sorts of obscure config tweaks with Pulseaudio.
- m45t3r 6y ago
  This looks that you're using very aggressive power settings in the kernel (powertop, tlp?), and doesn't seem related to PulseAudio at all.
cyborgx7 6y ago
This is giving me xkcd "Standards" vibes. https://xkcd.com/927/ https://xkcd.com/927/ I hope I'm wrong. There is a lot of potential to do better in that realm.
- spijdar 6y ago
  Given that it supports ALSA, PulseAudio, and JACK, I don't think it's like that at all. Assuming it works, it subsists of both all the other standards and a new one, keeping existing applications working with its own new advantages.
- declnz 6y ago
  Yeah but: the key differentiator to me is supplying drop-in replacements / adapters for all the other standards from early on in the process. This is why it isn't #927 I say...
- fit2rule 6y ago
  Rest your eyes on the delights that Linux standards can provideL http://zynthian.org/ http://zynthian.org/
tylerjl 6y ago
> Second, D-Bus was replaced as the IPC protocol. Instead, a native fully asynchronous protocol that was inspired by Wayland — without the XML serialization part — was implemented over Unix-domain sockets. Taymans wanted a protocol that is simple and hard-realtime safe. I'm surprised to read this; I was under the impression that D-Bus was the de jure path forward for interprocess communication like this. That's not to say I'm disappointed - the simpler, Unix-y style of domain sockets sounds much more in the style of what I hope for in a Linux service. I've written a little bit of D-Bus code and it always felt very ceremonial as opposed to "send bytes to this path". Are there any discussions somewhere about this s/D-Bus/domain socket/ trend, which the article implies is a broader movement given Wayland's similar decision as well?
- cycloptic 6y ago
  D-Bus isn't suitable for realtime, to get that to work would require additional changes within the D-Bus daemon to add realtime scheduling, and even with all that, it would still introduce latency because it requires an extra context switch from client -> dbus-daemon -> pipewire. Maybe they could have re-used the D-Bus wire format? That's the only bit that might have been suitable.
  - vlovich123 6y ago
    To this day I still don't understand why messages are routed through dbus-daemon instead of just using FD-passing to establish the p2p connection directly. I remember we were using D-Bus on WebOS @ Palm & a coworker rewrote the DBus internals (keeping the same API) to do just that & the performance win was significant (at least 10 years ago).
    - cycloptic 6y ago
      Among other things, pushing everything through the message bus allows for global message ordering, and security policies down to the individual message. Rewriting the internals would work in an embedded situation like that where every application is linking against the same version of libdbus, but that is not really the case on a desktop system, where there are multiple different D-Bus protocol implementations. If applications have hard performance requirements, most D-Bus implementations do have support for sending peer-to-peer messages, but applications have to set up and manage the socket themselves.
jancsika 6y ago
I'm just thinking of all the disparate use cases for Linux audio, all the disparate types of inputs/outputs, complex device types involved, etc. But then I think about pro-audio: * gotta go fast * devices don't suddenly appear and disappear after boot * hey Paul Davis-- isn't the current consensus that people just wanna run a single pro-audio software environment and run anything else they need as plugins within that environment? (As opposed to running a bazillion different applications and gluing them together with Jack?) So for pro-audio, rather than dev'ing more generic solutions to rule all the generic solutions (and hoping pro-audio still fits one of the generic-inside-generic nestings), wouldn't time be better spent creating a dead simple round-trip audio latency test GUI (and/or API), picking a reference distro, testing various alsa configurations to measure which one is most reliable at the lowest latency, and publishing the results? Perhaps start with most popular high-end devices, then work your way down from there... Or has someone done this already?
- cozzyd 6y ago
  But there's pro audio in a studio, and then there's people like me who occassionally record stuff on our normal desktop systems and find it annoying to remember / lookup how to switch audio stacks.
- ubercow13 6y ago
  Can't pro audio also mean plugging in your laptop at a nightclub and performing? Why is pro audio limited to things as unchanging as a permanent recording studio? Someone making tunes on their laptop in their bedroom can also require 'pro audio'.
voortuckian 6y ago
I believe Mars has the largest percentage by planet of linux machines with working sound. Is this audio/video bus a result of the space program?
- ncmncm 6y ago
  It is driven mainly by automotive uses. Modern instrument clusters in all cars are running Linux, and need to handle sound and video streams of terrifying variety, including dashcams, back-up cams, sirius radio, phone bluetooth, and more to come, directed to various display devices including actual screens, the instrument cluster, speakers, and phone calls.
alexfromapex 6y ago
The real link: https://pipewire.org/ https://pipewire.org/
- cozzyd 6y ago
  In this case, I disagree. LWN is always well worth reading.
squarefoot 6y ago
Does it also work with WINE and manages MIDI devices or it's audio only? From the project page on Gitlab it seems it doesn't; apologies for hijacking the thread if that's the case, but I'm out of ideas. I'm currently looking for a last resort before reinstalling everything since probably after an apt upgrade all native Linux software kept working perfectly with all my MIDI devices while all WINE applications simply stopped detecting them, no matter the software or WINE version used. No error messages, they suddenly just disappeared from every WINE application but kept working under native Linux. Audio still works fine in WINE software, they just can't be used with MIDI devices because according to them I have none. WINE and applications reinstalls didn't work.
yewenjie 6y ago
Can somebody please elaborate what does it mean for the user who installed `pulseaudio` once long ago and never had to bother about audio at all?
- eulers_secret 6y ago
  I'm curious as well. I've seen lots of folks talking about pipewire, but I'm a simple audio user - I want software mixing and audio out via a headphone jack and that's all. I'm pretty sure for most folks we'll just wait until our distro decides to move over, it'll happen in the background, and we'll not notice or care.
symlinkk 6y ago
I have never had problems with audio on Linux. What problems does this solve?
- tremon 6y ago
  Same thing that ALSA, esd, Pulseaudio and Phonon solved: the previous incarnation itched.
- MayeulC 6y ago
  Better sandboxing, basically. A system was needed for video, turns out it was a good fit for audio. Audio and video aren't that different, TBH (audio just has more alpha/blending rules, and lower tolerance on missed frames; video has higher bandwidth requirements). Wouldn't surprise me if both pipelines eventually completely converge. Both "need" compositors anyways.
- SilverRed 6y ago
  Consumer audio already works reasonably well but this apparently has massive improvements for bluetooth, especially the HFP profile which is used when using the built in headphones mic. The main benefit imo is to pro audio so you don't need to configure separate tools and manually swap between pulse and jack every time you want pro audio. It also manages permissions to record audio and the screen for wayland users.
moistbar 6y ago
Does anyone know if PipeWire can do audio streaming like PulseAudio can? I had a rather nice setup using a raspberry pi and an old stereo system a while back that I'd like to replicate.
- cycloptic 6y ago
  TCP sockets appear to still be supported by pipewire-pulse.
grawprog 6y ago
>JACK applications are supported through a re-implementation of the JACK client libraries and the pw-jack tool if both native and PipeWire JACK libraries are installed in parallel >unlike JACK, PipeWire uses timer-based audio scheduling. A dynamically reconfigurable timer is used for scheduling wake-ups to fill the audio buffer instead of depending on a constant rate of sound card interrupts. Beside the power-saving benefits, this allows the audio daemon to provide dynamic latency: higher for power-saving and consumer-grade audio like music playback; low for latency-sensitive workloads like professional audio. That's pretty interesting. It sounds like it's backwards compatible with jack programs but uses timer based scheduling similar to pulseaudio. Can you actually get the same low levels of latency needed for audio production without realtime scheduling? JACK's used over pulse for professional audio typically because of its realtime scheduling. How does pipewire provide low enough latency for recording or other audio production using timer based scheduling? Does anyone have any experience using pipewire for music recording or production? It would be nice to have one sound server, instead of three layered on top of eachother precariously, if it works well for music production.
jeffnappi 6y ago
This looks promising for Linux audio. I spent some time investigating the state of Linux audio servers a while back while diagnosing Bluetooth headset quality issues and ultimately opened this bug: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1838151 https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/18... Sounds like a lot of lessons have been learned from JACK, PulseAudio etc that have been factored in to the architecture of PipeWire. Maybe it really is the true coming of reliable Linux audio :)
robotbikes 6y ago
This is an exciting development. As someone who has supported the desktop use of Linux audio by community radio users I've found it very frustrating at times how things don't work. I remember a decade ago going to a presentation on Linux audio at Ohio Linux fest and the recently I decided to dive in and see what the best solution to coming up with a user friendly and fool proof audio setup (easier said than done). I found that JACK is still too complicated to setup for novices and pulse audio can just be inconsistent. So pipewire seems like it has a lot of potential and I'm excited that people are working on this. It'll perhaps make Linux audio better able to compete with coreAudio and whatever audio subsystem Windows uses. I especially appreciate that the flexibility and modularity allows both professional and consumer applications. The future is bright.
ncmncm 6y ago
Everybody had trouble with PulseAudio, even people who liked it in principle. LP wasn't joking about breaking sound: things did break, many, many times for many, many people, for years. And, almost always the only information readily available about what went wrong was just sound no longer coming out, or going in. And, almost always the reliable fix was to delete PA. But it really was often a consequence of something broken outside of PA. That doesn't mean there was always nothing the PA developers could do, and often they did. The only way it all ended up working as well as it does today--pretty well--is that those things finally got done, and bulldozed through the distro release pipelines. The result was that we gradually stopped needing to delete PA. Gstreamer crashed all the damn time, for a very long time, too. I never saw PA crash much. The thing is, all that most of us wanted, almost all the time, was for exactly one program to operate on sound at any time, with exactly one input device and one output device. UI warbling and meeping was never a high-value process. Mixing was most of the time an unnecessary complication and source of latency. The only complicated thing most of us ever wanted was to change routing to and from a headset when it was plugged or unplugged. ALSA was often wholly good enough at that. To this day, I have UI warbling and meeping turned off, not because it is still broken or might crash gstreamer, but because it is a net-negative feature. I am happiest that it is mostly easy to turn off. (I wish I could make my phone not scritch every damn time it sees a new wifi hub.) Pipewire benefits from things fixed to make PA work, so I have expectations that the transition will be quicker. But Pipewire is (like PA and Systemd) coded in a language that makes correct code much harder to write than buggy, insecure code; and Pipewire relies on not always necessarily especially mature kernel facilities. Those are both risk factors. I would be happier if Pipewire were coded in modern C++ (Rust is--let's be honest, at least with ourselves!--not portable enough yet), for reliability and security. I would be happier if it used only mature kernel features in its core operations, and dodgy new stuff only where needed for correspondingly dodgy Bluetooth configurations that nobody, seriously, expects ever to work anyway. What would go a long way to smoothing the transition would be a way to see, graphically, where it has stopped working. The graph in the article, annotated in real time with flow rates, sample rates, bit depths, buffer depths, and attenuation figures, would give us a hint about what is failing, with a finer resolution than "damn Pipewire". If we had such a thing for PA, it might have generated less animosity.
- 6y ago
shmerl 6y ago
I hope KDE will implement direct Pipewire support for general audio controls, to avoid going through the PulseAudio plugin.
josteink 6y ago
I wanted to give this a spin, but it’s seemingly not packaged in a meaningful way on Ubuntu yet. That is, there is no pipewire-pulse, pipewire-jack, etc. Oh well. Maybe next version?
- mfkp 6y ago
  I tried to get it running a few weeks ago on Ubuntu, but gave up. It's pretty simple on Arch or Fedora currently, but Ubuntu seems to be lacking the necessary packages. Hopefully soon.
  - josteink 6y ago
    I just tried building it from source, and in the end I got everything right... On paper. I got pulseaudio wrapped by pipewire-pulse, and applications launched and acted as if they produced audio (as opposed to being blocked), but I still couldn't get any sound. Granted I have a complicated setup with a laptop with 2 HDMI outputs, 2 USB-soundcards, built-in headphone adapter and a built-in speaker. Obviously that setup is going to take some configuration to get right, but with PulseAudio I could set it up pretty quickly with pavucontrol. No such luck with PipeWire ... yet. I guess it will get there sooner or later :)
ElijahLynn 6y ago
I actually read the whole thing as I have been wondering what this new word is, PipeWire, for a while now. I actually understood like 30% of this and think I'll get even more out of it in the future having read this.

457 points by darwi 6y ago

deleted 6y ago

[deleted]

xorcist 6y ago

What does real world latency look like with Pipewire? Is it comparable to jackd when used with something like Ardour?

dralley 6y ago
The FAQ provides some great information - no hard numbers though https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#dont-pro-audio-and-consumer-audio-have-conflicting-requirements https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ... https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#is-pipewire-another-jack-implementation https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ... https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#will-pipewire-ever-be-as-good-as-jack https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...
cptn_brittish 6y ago
It has a jack and pulseaudio api wrapper. I use it because it means I don't need to muck around with configuring pulse and jack to work nicely together.
fmoralesc 6y ago
Just tried recording from my laptop's mic - the reported latency from Ardour was 5,3ms (with 256 samples/buffer). It crashed when I went down to 128 samples/buffer.

nitsky 6y ago

PipeWire has worked very well for me both as a drop-in replacement for PulseAudio and to enable screen sharing on Wayland.

ledbettj 6y ago
It also worked as drop in replacement for PulseAudio for me, except all my audio now had stutters and pops. I ended up going back to Pulse. I got suggestions that I could go tweak buffer sizes stuff in a config file somewhere, but for my simple desktop use case I'd rather my audio just sounds right out of the box. Hopefully this sort of thing gets straightened out, because having to muck with config files to make my sound server actually work is like going back to working directly with ALSA or OSS.
- pkulak 6y ago
  I had a couple little issues as well when I switched over a couple months ago, but they just fell away over the ensuing weeks of updates until there's nothing left at the moment. Give it another try sometime soon.
  - cptn_brittish 6y ago
    I can confirm that a issue causing my audio to completely drop at random points resolved about 1 month ago and now everything works perfectly.
- andrewzah 6y ago
  FWIW I had issues with it on debian 10, until I built and installed it from master. It was a bit smoother on debian 11 but I couldn't get bluetooth to work.

dbrgn 6y ago

The fact that PipeWire has the potential to replace both PulseAudio (for consumer audio) and Jack (for pro audio) with a unified solution is very exciting.

bluGill 6y ago
Particularly if you are on the pro audio side. Consumer audio can ignore pro-audio for the most part. However everyone on pro-audio needs to do something consumer audio once in a while, if only to run a web browser.
- dbrgn 6y ago
  Exactly. If you're working on a project in Ardour and want to quickly watch a video on YouTube, stopping Jack and starting PulseAudio was a bit of a pain the last time I did that. Yes, you can configure PulseAudio as a Jack client, but the session handling is also a bit messy. (I used to have a PA -> Jack setup on my work computer just so I could use the Calf equalizer / compressor plugins for listening to music. I dropped it again after a while, because session handling and restoring wasn't always working properly. But that was around 6-7 years ago, maybe it would work better nowadays.)
- warmwaffles 6y ago
  What is pro audio? I'm naive when it comes to this.
  - dbrgn 6y ago
    Setups for professional music production. This usually requires JACK (https://jackaudio.org/ https://jackaudio.org/) as audio server, which allows synchronizing and connecting multiple applications. For example, you can have Ardour (https://ardour.org/ https://ardour.org/) as DAW, but use another application like Hydrogen (http://hydrogen-music.org/ http://hydrogen-music.org/) for creating drum samples. JACK connects the two applications using a virtual patchbay that allows using Hydrogen as an Input for Ardour. Essentially any application can be an input and/or an output. JACK also provides synchronization using a "master clock", so that Hydrogen starts playing as soon as you hit the "record" button in Ardour. Many people also use a Linux kernel optimized for low latency audio. With PulseAudio, these things are not possible. On the other hand, consumer applications like web browsers don't usually offer direct JACK support. So bridging is necessary, by using PulseAudio as a JACK input.

pta2002 6y ago

Just tried it on NixOS, had no idea it was so fleshed out already! Thought it'd be full of bugs but was pleasantly surprised, it just worked. No issues with compatibility, extremely low latency and has JACK and PulseAudio shims, so everything works out of the box, including pro audio stuff like Reaper and Ardour. And thanks to the JACK shim I can patch around the outputs with qjackctl. This is compared to JACK, which I never managed to properly combine with PulseAudio.

simias 6y ago
But does it work with the OSS shim for alsa shim for pulseaudio shim for jack shim for pipewire? Jokes aside my first reaction upon hearing about pipewire was "oh no, not yet an other Linux audio API" but maybe a miracle will happen and it'll be the Chosen One. I know that audio is hard but man the situation on Linux is such a terrible mess, not in small part because everybody reinvents the wheel instead of fixing the existing solutions. Jack is definitely the sanest of them all in my experience (haven't played with pipewire) but it's also not the most widely supported so I often run into frustrating issues with the compatibility layers.
- SilverRed 6y ago
  > not in small part because everybody reinvents the wheel instead of fixing the existing solutions. I'm using all of these reinventions. Wayland, systemd, flatpak, btrfs and soon pipewire. I'm absolutely loving linux right now. Everything works so nice in a way it will never on a distro with legacy tools. Some of these projects like flatpak have a few rough edges but the future is very bright for them and most problems seem very short term rather than architectural.
- bisby 6y ago
  I also liked JACK the best. But was frustrated with compatibility layers. Pipewire lets me use all the JACK tooling, but without needing a special compat layer to manage it. so for now, I'm pretty excited Still havent figured out how to get anything working for video.
kevincox 6y ago

londons_explore 6y ago

Without audio buffer rewinding, you're going to have to suffer random stutters and jumpiness every time your system comes under heavy load. Your system does an NMI because you plugged the power cable in? Your audio will glitch. It will also mean you won't be able to sit with an idle CPU while playing music - the audio daemon will have to wake up to reload buffers multiple times per second, killing battery life unacceptably for playing audiobooks on a phone... Saying rewindable audio is a non-feature might simplify the codebase, but if it makes it work badly for most use cases, it ought to be rethought.

freeqaz 6y ago
I'm not sure I understand this. Why can't you just increase buffer sizes and write more data to them to avoid frequency of wake ups? Edit: does this help? https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#pipewire-buffering-explained https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...
- phkahler 6y ago
  Low latency is a goal. From video conferencing to music recording it's very important.
  - robert_foss 6y ago
    I think supporting the low latency usecase is a goal, but not the only one. As far as I understand it pipewire provides configurable latency.
  - jjoonathan 6y ago
    Eh, just process all audio in a once-a-day batch job at 2am, it'll be great!
  - jancsika 6y ago
    Except that professional music recording is a domain in which low latency always trumps power consumption. So if a system based on such a tradeoff fails even once due to complexity of buffer rewinding or whatever, the professional musician loses. Hell, Jack could be re-implemented as power-hungry, ridiculous blockchain tech and if it resulted in round-trip latency / 2 professional musicians would still use it. Edit: added "complexity of" for clarification

nialv7 6y ago

pipewire already works surprisingly well. Even bluetooth source and sink works. Only problems I had so far are: * sometimes bluetooth devices would connect but not output audio, have to restart pipewire. * sometimes pipewire gets confusing and doesn't assign audio outputs properly. (shows up in pavucontrol as "Unknown output")

chenxiaolong 6y ago

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync. * DMA-BUF based screen recording works with OBS + obs-xdg-portal + pipewire (for 60fps game capture). For my use cases, the only things still missing are automatic switching between A2DP and HFP bluetooth profiles and support for AVRCP absolute volume (so that the OS changes the headset's hardware volume instead of having a separate software volume).

foobarbecue 6y ago
Did you get 2—way (in & out) 16khz Bluetooth to work? Am I right that this isn't possible?
- chenxiaolong 6y ago
  I believe when the HFP profile is used and mSBC is supported, then mSBC is used for both the input and output.
Abishek_Muthian 6y ago
Would there be improvements for remote audio streaming over pulseaudio with ssh?
- chenxiaolong 6y ago
  I'm not sure about this one. I haven't tried streaming audio over the network with either pulseaudio or pipewire.
JeremyNT 6y ago
If you use Arch Linux, it's really easy to just drop this right in from official packages as a replacement for Pulse/ALSA [0] and start using it. I've been running it for about a month and everything seems to work exactly as I expect it to. I honestly notice no difference other than the pulse audio input/output picker extension I had been using seems confused now (the native GNOME sound control panel applet works just fine though). On the video front I use obs-xdg-portal for Wayland screen capture as well - finally there's a good story for doing this! You even get a nifty permission dialogue in GNOME. You have to launch OBS in forced wayland mode with 'QT_QPA_PLATFORM=wayland obs' [0] https://wiki.archlinux.org/index.php/Pipewire#Audio https://wiki.archlinux.org/index.php/Pipewire#Audio

superluserdo 6y ago

Does anyone know if pipewire has its own audio protocol for applications, as well as taking the place of JACK and Pulse? Or will future applications still just decide whether to talk to "JACK" or "Pulseaudio"? (Both actually being pipewire)

bitbang 6y ago
It does. The support for Pulse and JACK APIs is to ease adoption.

OJFord 6y ago

It's great to see pipewire coming along, pulseaudio development seems to (to a spectator) to have been a little.. well.. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/227#note_712800 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge... https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/288#note_713222 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...

entropie 6y ago
This is so sad. I had no idea.
uluyol 6y ago
Isn't this probably because most developers have shifted focus on PipeWire? I thought both came from more-or-less the same community?
dralley 6y ago
While that seems like a huge cluster, it does kind of seem that the patch rejections come from a set of principles. If the patches would improve Bluetooth audio at the expense of breaking existing features, saying "we don't break existing features" is a valid position to hold.
- rcxdude 6y ago
  I don't think the issue was breaking existing features, it was a classic 'perfect being the enemy of good' situation. PA maintainers wanted to support dynamically loading the involved codecs due to potential (but not particularly well demonstrated) concerns about licensing and inclusion in certain distros. But they didn't really have the manpower to actually do this (and especially they disagreed with the person actually doing the work on how to go about doing this), so they just sat on an MR for ages while the situation improved for no-one (worst case it gets merged and then disabled at compile time by some distros). Meanwhile frustrations arose because the contributer wanted to help users and the maintainers just seemed like a roadblock to doing this, and the maintainers utterly failed to de-escalate the situation.
6y ago

onli 6y ago

> including the raw Linux ALSA sound API, which typically allows only one application to access the sound card. If the raw in that sentence is not meant as a special qualifier and this is meant as a statement about ALSA in general, this is wrong. I recently read up on this to confirm my memory was right when reading a similar statement. In fact, ALSA had just a very short period where typically only one application accessed the sound card. After that, dmix was enabled by default. Supporting multiple applications was actually the big advantage of ALSA compared to OSS, which at the time really did support only one application per soundcard (without hardware mixing, which broke away at that time). I'm not sure why this seems to be remembered so wrongly? > Speaking of transitions, Fedora 8's own switch to PulseAudio in late 2007 was not a smooth one. Longtime Linux users still remember having the daemon branded as the software that will break your audio. This wasn't just a Fedora problem. Ubuntu when making the switch also broke Audio on countless of systems. I was active as supporter in a Ubuntu support forum at that time and we got flooded with help requests. My very own system did not work with Pulseaudio when I tried to switch, that was years later. I still use only ALSA because of that experience. At that time Pulseaudio was garbage, it should never have been used then. It only got acceptable later - but still has bugs and issues. That said, PipeWire has a better vibe than Pulseaudio did. It intends to replace a system that never worked flawlessly, seems to focus on compatibility, and the apparent endorsement from the JACK-developers also does not hurt. User reports I have seen so far have been positive, though I'm not deep into support forums anymore. Maybe this can at least replace Pulseaudio, that would be a win. I'm cautiously optimistic about this one.

jcastro 6y ago
> I'm not sure why this seems to be remembered so wrongly? It didn't work reliably on all chipsets/soundcards.
- onli 6y ago
  I don't remember this at all, but this might explain that. Or maybe a distribution like debian stable shipped with an outdated ALSA version, taken from the short period between release and dmix. Or just disabled dmix. Would love if someone remembered specifics. I kinda assumed people mix up Alsa and OSS or don't remember anymore what actually did and what did not work before Pulseaudio was introduced.

gmueckl 6y ago

Nah, another audio daemon is not what Linux needs IMO. This should be merged into the kernel, especially since process isolation is one of the stated goals. Running hard realtime stuff in a user space that is designed to not provide useful guarantees related to hard deadlines is brave, but ultimately somewhat foolish. I know that there are arguments against having high quality audio rate resampling inside the kernel that are routinely brought up to block any kind of useful sound mixing and routing inside the kernel. But I think that all necessary resampling can easily be provided as part of the user space API wrapper that hands buffers off to the kernel. And the mixing can be handled in integer maths, including some postprocessing. Device specific corrections (e.g. output volume dependent equalization) can also fit into the kernel audio subsystem if so desired. AFAIK, Windows runs part of the Audio subsystem outside the kernel, but these processes get special treatment by the scheduler to meet deadlines. And the system is built in a way that applications have no way to touch these implementation details. On Linux, the first thing audio daemons do is break the kernel provided interface and forcing applications to become aware of yet another audio API that may or may not be present. This is just my general opinion on how the design of the Linux audio system is lacking. I am aware that it's probably not a terribly popular opinion. No need to hate me for it. [End of rambling.]

tinco 6y ago
I only read this article, so I'm still fuzzy on the exact technical details, but couldn't a system like pipewire eventually be adopted into the kernel after it has proven itself adequate? Or is that not a thing the kernel does?
- bitbang 6y ago
  Probably not. Kernel handles the hardware. User-space deals with things like routing, mixing, resampling, fx, etc. Having that functionality outside of the kernel offers a lot more flexibility. Despite people chafing at the user-space audio API churn, it does allow advancements that would be much more difficult to do if implemented in the kernel.
regularfry 6y ago
Crossing the streams a bit, I'm wondering if there's enough grunt in EBPF to do mixing and resampling.

sp1rit 6y ago

I'm currently trying pipewire on openSUSE Tumbleweed. I'm very impressed with it so far. (After realizing it was broken, because I didn't have the pipewire-alsa package installed => No audio devices) The pulse drop-in worked flawlessly out of the box. I'd had some isssues with the jack drop-in libraries tho. (metalic voice, basically not useable) To fix this, I had to change the sample rate in /etc/pipewire/pipewire.cfg from the default 48000 to 44100.

Arnavion 6y ago
Have you been using some GUI to be able to control volume, etc? I've been holding out on replacing PA with PW on Tumbleweed until [1] is resolved so I can continue using pavucontrol (pavucontrol's deps will be satisfied by pipewire-pulseaudio and not only pulseaudio), which is currently blocked at [2] being accepted. Probably another week or so. [1]: https://bugzilla.opensuse.org/show_bug.cgi?id=1182730 https://bugzilla.opensuse.org/show_bug.cgi?id=1182730 [2]: https://build.opensuse.org/request/show/875208 https://build.opensuse.org/request/show/875208

alvatar 6y ago

I hope this fixes my issues with bluetooth on Linux. When I'm on battery the audio breaks all the time. I've tried all sorts of obscure config tweaks with Pulseaudio.

m45t3r 6y ago
This looks that you're using very aggressive power settings in the kernel (powertop, tlp?), and doesn't seem related to PulseAudio at all.

cyborgx7 6y ago

This is giving me xkcd "Standards" vibes. https://xkcd.com/927/ https://xkcd.com/927/ I hope I'm wrong. There is a lot of potential to do better in that realm.

spijdar 6y ago
Given that it supports ALSA, PulseAudio, and JACK, I don't think it's like that at all. Assuming it works, it subsists of both all the other standards and a new one, keeping existing applications working with its own new advantages.
declnz 6y ago
Yeah but: the key differentiator to me is supplying drop-in replacements / adapters for all the other standards from early on in the process. This is why it isn't #927 I say...
fit2rule 6y ago
Rest your eyes on the delights that Linux standards can provideL http://zynthian.org/ http://zynthian.org/

tylerjl 6y ago

> Second, D-Bus was replaced as the IPC protocol. Instead, a native fully asynchronous protocol that was inspired by Wayland — without the XML serialization part — was implemented over Unix-domain sockets. Taymans wanted a protocol that is simple and hard-realtime safe. I'm surprised to read this; I was under the impression that D-Bus was the de jure path forward for interprocess communication like this. That's not to say I'm disappointed - the simpler, Unix-y style of domain sockets sounds much more in the style of what I hope for in a Linux service. I've written a little bit of D-Bus code and it always felt very ceremonial as opposed to "send bytes to this path". Are there any discussions somewhere about this s/D-Bus/domain socket/ trend, which the article implies is a broader movement given Wayland's similar decision as well?

cycloptic 6y ago
D-Bus isn't suitable for realtime, to get that to work would require additional changes within the D-Bus daemon to add realtime scheduling, and even with all that, it would still introduce latency because it requires an extra context switch from client -> dbus-daemon -> pipewire. Maybe they could have re-used the D-Bus wire format? That's the only bit that might have been suitable.
- vlovich123 6y ago
  To this day I still don't understand why messages are routed through dbus-daemon instead of just using FD-passing to establish the p2p connection directly. I remember we were using D-Bus on WebOS @ Palm & a coworker rewrote the DBus internals (keeping the same API) to do just that & the performance win was significant (at least 10 years ago).
  - cycloptic 6y ago
    Among other things, pushing everything through the message bus allows for global message ordering, and security policies down to the individual message. Rewriting the internals would work in an embedded situation like that where every application is linking against the same version of libdbus, but that is not really the case on a desktop system, where there are multiple different D-Bus protocol implementations. If applications have hard performance requirements, most D-Bus implementations do have support for sending peer-to-peer messages, but applications have to set up and manage the socket themselves.

jancsika 6y ago

I'm just thinking of all the disparate use cases for Linux audio, all the disparate types of inputs/outputs, complex device types involved, etc. But then I think about pro-audio: * gotta go fast * devices don't suddenly appear and disappear after boot * hey Paul Davis-- isn't the current consensus that people just wanna run a single pro-audio software environment and run anything else they need as plugins within that environment? (As opposed to running a bazillion different applications and gluing them together with Jack?) So for pro-audio, rather than dev'ing more generic solutions to rule all the generic solutions (and hoping pro-audio still fits one of the generic-inside-generic nestings), wouldn't time be better spent creating a dead simple round-trip audio latency test GUI (and/or API), picking a reference distro, testing various alsa configurations to measure which one is most reliable at the lowest latency, and publishing the results? Perhaps start with most popular high-end devices, then work your way down from there... Or has someone done this already?

cozzyd 6y ago
But there's pro audio in a studio, and then there's people like me who occassionally record stuff on our normal desktop systems and find it annoying to remember / lookup how to switch audio stacks.
ubercow13 6y ago
Can't pro audio also mean plugging in your laptop at a nightclub and performing? Why is pro audio limited to things as unchanging as a permanent recording studio? Someone making tunes on their laptop in their bedroom can also require 'pro audio'.

voortuckian 6y ago

I believe Mars has the largest percentage by planet of linux machines with working sound. Is this audio/video bus a result of the space program?

ncmncm 6y ago
It is driven mainly by automotive uses. Modern instrument clusters in all cars are running Linux, and need to handle sound and video streams of terrifying variety, including dashcams, back-up cams, sirius radio, phone bluetooth, and more to come, directed to various display devices including actual screens, the instrument cluster, speakers, and phone calls.

alexfromapex 6y ago

The real link: https://pipewire.org/ https://pipewire.org/

cozzyd 6y ago
In this case, I disagree. LWN is always well worth reading.

squarefoot 6y ago

Does it also work with WINE and manages MIDI devices or it's audio only? From the project page on Gitlab it seems it doesn't; apologies for hijacking the thread if that's the case, but I'm out of ideas. I'm currently looking for a last resort before reinstalling everything since probably after an apt upgrade all native Linux software kept working perfectly with all my MIDI devices while all WINE applications simply stopped detecting them, no matter the software or WINE version used. No error messages, they suddenly just disappeared from every WINE application but kept working under native Linux. Audio still works fine in WINE software, they just can't be used with MIDI devices because according to them I have none. WINE and applications reinstalls didn't work.

yewenjie 6y ago

Can somebody please elaborate what does it mean for the user who installed `pulseaudio` once long ago and never had to bother about audio at all?

eulers_secret 6y ago
I'm curious as well. I've seen lots of folks talking about pipewire, but I'm a simple audio user - I want software mixing and audio out via a headphone jack and that's all. I'm pretty sure for most folks we'll just wait until our distro decides to move over, it'll happen in the background, and we'll not notice or care.

symlinkk 6y ago

I have never had problems with audio on Linux. What problems does this solve?

tremon 6y ago
Same thing that ALSA, esd, Pulseaudio and Phonon solved: the previous incarnation itched.
MayeulC 6y ago
Better sandboxing, basically. A system was needed for video, turns out it was a good fit for audio. Audio and video aren't that different, TBH (audio just has more alpha/blending rules, and lower tolerance on missed frames; video has higher bandwidth requirements). Wouldn't surprise me if both pipelines eventually completely converge. Both "need" compositors anyways.
SilverRed 6y ago
Consumer audio already works reasonably well but this apparently has massive improvements for bluetooth, especially the HFP profile which is used when using the built in headphones mic. The main benefit imo is to pro audio so you don't need to configure separate tools and manually swap between pulse and jack every time you want pro audio. It also manages permissions to record audio and the screen for wayland users.

moistbar 6y ago

Does anyone know if PipeWire can do audio streaming like PulseAudio can? I had a rather nice setup using a raspberry pi and an old stereo system a while back that I'd like to replicate.

cycloptic 6y ago
TCP sockets appear to still be supported by pipewire-pulse.

grawprog 6y ago

>JACK applications are supported through a re-implementation of the JACK client libraries and the pw-jack tool if both native and PipeWire JACK libraries are installed in parallel >unlike JACK, PipeWire uses timer-based audio scheduling. A dynamically reconfigurable timer is used for scheduling wake-ups to fill the audio buffer instead of depending on a constant rate of sound card interrupts. Beside the power-saving benefits, this allows the audio daemon to provide dynamic latency: higher for power-saving and consumer-grade audio like music playback; low for latency-sensitive workloads like professional audio. That's pretty interesting. It sounds like it's backwards compatible with jack programs but uses timer based scheduling similar to pulseaudio. Can you actually get the same low levels of latency needed for audio production without realtime scheduling? JACK's used over pulse for professional audio typically because of its realtime scheduling. How does pipewire provide low enough latency for recording or other audio production using timer based scheduling? Does anyone have any experience using pipewire for music recording or production? It would be nice to have one sound server, instead of three layered on top of eachother precariously, if it works well for music production.

jeffnappi 6y ago

This looks promising for Linux audio. I spent some time investigating the state of Linux audio servers a while back while diagnosing Bluetooth headset quality issues and ultimately opened this bug: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1838151 https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/18... Sounds like a lot of lessons have been learned from JACK, PulseAudio etc that have been factored in to the architecture of PipeWire. Maybe it really is the true coming of reliable Linux audio :)

robotbikes 6y ago

This is an exciting development. As someone who has supported the desktop use of Linux audio by community radio users I've found it very frustrating at times how things don't work. I remember a decade ago going to a presentation on Linux audio at Ohio Linux fest and the recently I decided to dive in and see what the best solution to coming up with a user friendly and fool proof audio setup (easier said than done). I found that JACK is still too complicated to setup for novices and pulse audio can just be inconsistent. So pipewire seems like it has a lot of potential and I'm excited that people are working on this. It'll perhaps make Linux audio better able to compete with coreAudio and whatever audio subsystem Windows uses. I especially appreciate that the flexibility and modularity allows both professional and consumer applications. The future is bright.

ncmncm 6y ago

Everybody had trouble with PulseAudio, even people who liked it in principle. LP wasn't joking about breaking sound: things did break, many, many times for many, many people, for years. And, almost always the only information readily available about what went wrong was just sound no longer coming out, or going in. And, almost always the reliable fix was to delete PA. But it really was often a consequence of something broken outside of PA. That doesn't mean there was always nothing the PA developers could do, and often they did. The only way it all ended up working as well as it does today--pretty well--is that those things finally got done, and bulldozed through the distro release pipelines. The result was that we gradually stopped needing to delete PA. Gstreamer crashed all the damn time, for a very long time, too. I never saw PA crash much. The thing is, all that most of us wanted, almost all the time, was for exactly one program to operate on sound at any time, with exactly one input device and one output device. UI warbling and meeping was never a high-value process. Mixing was most of the time an unnecessary complication and source of latency. The only complicated thing most of us ever wanted was to change routing to and from a headset when it was plugged or unplugged. ALSA was often wholly good enough at that. To this day, I have UI warbling and meeping turned off, not because it is still broken or might crash gstreamer, but because it is a net-negative feature. I am happiest that it is mostly easy to turn off. (I wish I could make my phone not scritch every damn time it sees a new wifi hub.) Pipewire benefits from things fixed to make PA work, so I have expectations that the transition will be quicker. But Pipewire is (like PA and Systemd) coded in a language that makes correct code much harder to write than buggy, insecure code; and Pipewire relies on not always necessarily especially mature kernel facilities. Those are both risk factors. I would be happier if Pipewire were coded in modern C++ (Rust is--let's be honest, at least with ourselves!--not portable enough yet), for reliability and security. I would be happier if it used only mature kernel features in its core operations, and dodgy new stuff only where needed for correspondingly dodgy Bluetooth configurations that nobody, seriously, expects ever to work anyway. What would go a long way to smoothing the transition would be a way to see, graphically, where it has stopped working. The graph in the article, annotated in real time with flow rates, sample rates, bit depths, buffer depths, and attenuation figures, would give us a hint about what is failing, with a finer resolution than "damn Pipewire". If we had such a thing for PA, it might have generated less animosity.

6y ago

shmerl 6y ago

I hope KDE will implement direct Pipewire support for general audio controls, to avoid going through the PulseAudio plugin.

josteink 6y ago

I wanted to give this a spin, but it’s seemingly not packaged in a meaningful way on Ubuntu yet. That is, there is no pipewire-pulse, pipewire-jack, etc. Oh well. Maybe next version?

mfkp 6y ago
I tried to get it running a few weeks ago on Ubuntu, but gave up. It's pretty simple on Arch or Fedora currently, but Ubuntu seems to be lacking the necessary packages. Hopefully soon.
- josteink 6y ago
  I just tried building it from source, and in the end I got everything right... On paper. I got pulseaudio wrapped by pipewire-pulse, and applications launched and acted as if they produced audio (as opposed to being blocked), but I still couldn't get any sound. Granted I have a complicated setup with a laptop with 2 HDMI outputs, 2 USB-soundcards, built-in headphone adapter and a built-in speaker. Obviously that setup is going to take some configuration to get right, but with PulseAudio I could set it up pretty quickly with pavucontrol. No such luck with PipeWire ... yet. I guess it will get there sooner or later :)

ElijahLynn 6y ago

I actually read the whole thing as I have been wondering what this new word is, PipeWire, for a while now. I actually understood like 30% of this and think I'll get even more out of it in the future having read this.