PipeWire: The Linux audio/video bus
For more than a decade, PulseAudio has been serving the Linux desktop as its predominant audio mixing and routing daemon — and its audio API. Unfortunately, PulseAudio's internal architecture does not fit the growing sandboxed-applications use case, even though there have been attempts to amend that. PipeWire, a new daemon created (in part) out of these attempts, will replace PulseAudio in the upcoming Fedora 34 release. It is a coming transition that deserves a look.
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. After a bumpy start, PulseAudio emerged as the winner of the Linux sound-server struggles. It provided a native client audio API, but also supported applications that used the common audio APIs of the time — including the raw Linux ALSA sound API, which typically allows only one application to access the sound card. PulseAudio mixed the different applications' audio streams and provided a central point for audio management, fine-grained configuration, and seamless routing to Bluetooth, USB, or HDMI. It positioned itself as the Linux desktop equivalent of the user-mode audio engine for Windows Vista and the macOS CoreAudio daemon.
Cracks at PulseAudio
By 2015, PulseAudio was still enjoying its status as the de facto Linux audio daemon, but cracks were beginning to develop. The gradual shift to sandboxed desktop applications may be proving fatal to its design: with PulseAudio, an application can snoop on other applications' audio, have unmediated access to the microphone, or load server modules that can interfere with other applications. Attempts were made at fixing PulseAudio, mainly through an access-control layer and a per-client memfd-backed transport. This was all necessary but not yet sufficient for isolating clients' audio.
Around that time, David Henningson, one of the core PulseAudio developers, resigned from the project. He cited frustrations over the daemon's poor fit for the sandboxed-applications use case, and its intermixing of mechanism and policy for audio-routing decisions. At the end of his message, he wondered if the combination of these problems might be the birth pangs of a new and much-needed Linux audio daemon:
In software nothing is impossible, but to re-architecture PulseAudio to support all of these requirements in a good way (rather than to "build another layer on top" […]) would be very difficult, so my judgment is that it would be easier to write something new from scratch.
And I do think it would be possible to write something that took the best from PulseAudio, JACK, and AudioFlinger, and get something that would work well for both mobile and desktop; for pro-audio, gaming, low-power music playback, etc. […] I think we, as an open source community, could have great use for such a sound server.
PulseVideo to Pinos
Meanwhile, GStreamer co-creator Wim Taymans was asked to work on a Linux service to mediate web browsers' access to camera devices. Initially, he called the project PulseVideo. The idea behind the name was simple: similar to the way PulseAudio was created to mediate access to ALSA sound devices, PulseVideo was created to mediate and multiplex access to the Video4Linux2 camera device nodes.
A bit later, Taymans discovered a similarly-named PulseVideo prototype [video], created by William Manley, and helped in upstreaming the GStreamer features required by its code. To avoid conflicts with the PulseAudio name, and due to scope extension beyond just camera access, Taymans later renamed the project to Pinos — in a reference to his town of residence in Spain.
Pinos was built on top of GStreamer pipelines, using some of the infrastructure that was earlier refined for Manley's prototype. D-Bus with file-descriptor passing was used for interprocess communication. At the GStreamer 2015 conference, Taymans described the Pinos architecture [PDF] to attendees and gave a demo of multiple applications accessing the system camera feed in parallel.
Due to its flexible, pipeline-based, file-descriptor-passing architecture, Pinos also supported media broadcasting in the other direction: applications could "upload" a media stream by passing a memfd or dma-buf file descriptor. The media stream can then be further processed and distributed to other applications and system multimedia sinks like ALSA sound devices.
While only discussed in passing, the ability to send streams in both directions and across applications allowed Pinos to act as a generic audio/video bus — efficiently funneling media between isolated, and possibly sandboxed, user processes. The scope of Pinos (if properly extended) could thus overlap with, and possibly replace, PulseAudio. Taymans was explicitly asked that question [video, 31:35], and he answered: "Replacing PulseAudio is not an easy task; it's not on the agenda [...] but [Pinos] is very broad, so it could do more later."
As the PulseAudio deficiencies discussed in the earlier section became more problematic, "could do more later" was not a far-off target.
PipeWire
By 2016, Taymans started rethinking the foundations of Pinos, extending its scope to become the standard Linux audio/video daemon. This included the "plenty of tiny buffers" low-latency audio use case typically covered by JACK. There were two main areas that needed to be addressed.
First, the hard dependency on GStreamer elements and pipelines for the core daemon and client libraries proved problematic. GStreamer has plenty of behind-the-scenes logic to achieve its flexibility. During the processing of a GStreamer pipeline, done within the context of Pinos realtime threads, this flexibility came at the cost of implicit memory allocations, thread creation, and locking. These are all actions that are well-known to negatively affect the predictability needed for hard realtime code.
To achieve part of the GStreamer pipelines' flexibility while still satisfying hard realtime requirements, Taymans created a simpler multimedia pipeline framework and called it SPA — the Simple Plugin API [PDF]. The framework is designed to be safely executed from realtime threads (e.g. Pinos media processing threads), with a specific time budget that should never be exceeded. SPA performs no memory allocations; instead, those are the sole responsibility of the SPA framework application.
Each node has a well-defined set of states. There is a state for configuring the node's ports, formats, and buffers — done by the main (non-realtime) thread, a state for the host to allocate all the necessary buffers required by the node after its configuration, and a separate state where the actual processing is done in the realtime threads. During streaming, if any of the media pipeline nodes change state (e.g. due to an event), the realtime threads can be notified so that control is switched back to the main thread for reconfiguration.
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.
By the time the SPA framework was integrated and a native IPC protocol was developed, the project had long-outgrown its original purpose: from a D-Bus daemon for sharing camera access to a full realtime-capable audio/video bus. It was thus renamed again, to PipeWire — reflecting its new status as a prominent pipeline-based engine for multimedia sharing and processing.
Lessons learned
From the start, the PipeWire developers applied an essential set of lessons from existing audio daemons like JACK, PulseAudio, and the Chromium OS Audio Server (CRAS). Unlike PulseAudio's intentional division of the Linux audio landscape into consumer-grade versus professional realtime audio, PipeWire was designed from the start to handle both. To avoid the PulseAudio sandboxing limitations, security was baked-in: a per-client permissions bitfield is attached to every PipeWire node — where one or more SPA nodes are wrapped. This security-aware design allowed easy and safe integration with Flatpak portals; the sandboxed-application permissions interface now promoted to a freedesktop XDG standard.
Like CRAS and PulseAudio, but 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.
Similar to CRAS, but unlike PulseAudio, PipeWire is not modeled on top of audio-buffer rewinding. When timer-based audio scheduling is used with huge buffers (as in PulseAudio), support for rewriting the sound card's buffer is needed to provide a low-latency response to unpredictable events like a new audio stream or a stream's volume change. The big buffer already sent to the audio device must be revoked and a new buffer needs to be submitted. This has resulted in significant code complexity and corner cases [PDF]. Both PipeWire and CRAS limit the maximum latency/buffering to much lower values — thus eliminating the need for buffer rewinding altogether.
Like JACK, PipeWire chose an external-session-manager setup. Professional audio users typically build their own audio pipelines in a session-manager application like Catia or QjackCtl, then let the audio daemon execute the final result. This has the benefit of separating policy (how the media pipeline is built) from mechanism (how the audio daemon executes the pipeline). At GUADEC 2018, developers explicitly asked Taymans [video, 23:15] to let GNOME, and possibly other external daemons, take control of that part of the audio stack. Several system integrators had already run into problems because PulseAudio embeds audio-routing policy decisions deep within its internal modules code. This was also one of the pain points mentioned in Henningson's resignation e-mail.
Finally, following the trend of multiple influential system daemons created in the last decade, PipeWire makes extensive use of Linux-kernel-only APIs. This includes memfd, eventfd, timerfd, signalfd, epoll, and dma-buf — all of which make the "file-descriptor" the primary identifier for events and shared buffers in the system. PipeWire's support for importing dma-buf file descriptors was key in implementing efficient Wayland screen capture and recording. For large 4K and 8K screens, the CPU does not need to touch any of the massive GPU buffers: GNOME mutter (or similar applications) passes a dma-buf descriptor that can then be integrated into PipeWire's SPA pipelines for further processing and capturing.
Adoption
The native PipeWire API has been declared stable since the project's major 0.3 release. Existing raw ALSA applications are supported through a PipeWire ALSA plugin. 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. PulseAudio applications are supported through a pipewire-pulse daemon that listens to PulseAudio's own socket and implements its native communication protocol. This way, containerized desktop applications that use their own copy of the native PulseAudio client libraries are still supported. WebRTC, the communication framework (and code) used by all major browsers, includes native PipeWire support for Wayland screen sharing — mediated through a Flatpak portal.
The graph below shows a PipeWire media pipeline, generated using pw-dot then slightly beautified, on an Arch Linux system. A combination of PipeWire-native and PulseAudio-native applications is shown:
![[PipeWire
pipeline]](https://static.lwn.net/images/2021/pipewire-pipeline-sm.png "PipeWire pipeline")
On the left, both GNOME Cheese and a GStreamer pipeline instance created with gst-launch-1.0 are accessing the same camera feed in parallel. In the middle, Firefox is sharing the system screen (for a Jitsi meeting) using WebRTC and Flatpak portals. On the right, the Spotify music player (a PulseAudio app) is playing audio, which is routed to the system's default ALSA sink — with GNOME Settings (another PulseAudio app) live-monitoring the Left/Right channel status of that sink.
On the Linux distributions side of things, Fedora has been shipping the PipeWire daemon (only for Wayland screen capture) since its Fedora 27 release. Debian offers PipeWire packages, but replacing PulseAudio or JACK is "an unsupported use case." Arch Linux provides PipeWire in its central repository and officially offers extra packages for replacing both PulseAudio and JACK, if desired. Similarly, Gentoo provides extensive documentation for replacing both daemons. The upcoming Fedora 34 release will be the first Linux distribution that will have PipeWire fully replace PulseAudio by default and out of the box.
Overall, this is a critical period in the Linux multimedia scene. While open source is a story about technology, it's also a story about the people hard at work creating it. There has been a notable agreement from both PulseAudio and JACK developers that PipeWire and its author are on the right track. The upcoming Fedora 34 release should provide a litmus test for PipeWire's Linux distributions adoption moving forward.
| Index entries for this article | |
|---|---|
| GuestArticles | Darwish, Ahmed S. |
Posted Mar 2, 2021 21:55 UTC (Tue)
by josh (subscriber, #17465)
[Link] (12 responses)
Posted Mar 2, 2021 23:14 UTC (Tue)
by tchernobog (guest, #73595)
[Link] (2 responses)
Posted Mar 3, 2021 0:29 UTC (Wed)
by josh (subscriber, #17465)
[Link] (1 responses)
Posted Mar 3, 2021 21:29 UTC (Wed)
by westurner (guest, #145208)
[Link]
From https://github.com/muammar/mkchromecast :
> [mkchromecast] is a program to cast your macOS audio, or Linux audio to your Google Cast devices or Sonos speakers. It can also cast video files.
> It is written for Python3, and it can stream via node.js, parec (Linux), ffmpeg, or avconv. Mkchromecast is capable of using lossy and lossless audio formats provided that ffmpeg, avconv (Linux), or parec (Linux) are installed. It also supports Multi-room group playback, and 24-bit/96kHz high audio resolution. Additionally, a system tray menu is available.
Posted Mar 3, 2021 16:22 UTC (Wed)
by NightMonkey (subscriber, #23051)
[Link] (3 responses)
Posted Mar 4, 2021 14:42 UTC (Thu)
by mgedmin (subscriber, #34497)
[Link] (2 responses)
(Much much later I realized that this was probably NetworkManager asking my WiFi card to scan for available networks periodically, which interrupted the PulseAudio stream sufficiently long to cause sound dropouts.)
Posted Mar 5, 2021 8:11 UTC (Fri)
by lathiat (subscriber, #18567)
[Link]
Safe to say it might be worth trying again ;)
Posted Mar 13, 2021 13:24 UTC (Sat)
by mkbosmans (subscriber, #65556)
[Link]
Yes, I think some of those problems were fixed about 10 years ago, with this commit and some of its parents:
But those were of course fixes related to general buffer underrun, network latency and clock drift problems. For a periodically interrupted network connection the only solution would be larger buffers, thus more latency for network playback.
Posted Mar 3, 2021 18:10 UTC (Wed)
by fratti (guest, #105722)
[Link] (4 responses)
Posted Mar 3, 2021 20:52 UTC (Wed)
by josh (subscriber, #17465)
[Link] (3 responses)
I asked if someone had any efforts to make the two work together. I did *not* imply at any point that it was someone's job or obligation to do so.
Posted Mar 4, 2021 8:28 UTC (Thu)
by andreashappe (subscriber, #4810)
[Link] (2 responses)
Posted Mar 14, 2021 3:59 UTC (Sun)
by calumapplepie (guest, #143655)
[Link]
Posted Mar 14, 2021 4:47 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Hey, it seems to be working!
Posted Mar 3, 2021 2:03 UTC (Wed)
by gerdesj (subscriber, #5446)
[Link] (42 responses)
I've been running the thing on Arch for a month or two now and it seems quite stable. I plug in my USB headset and fire up Teams (*sigh* yes) and usually I get better audio than my Windows sporting colleagues. At least one or two will have a broken audio setup at any time. Then there's that SOF project thing.
It all seems to hang together for me at the moment, which is nice. When my Samsung bluetooth earbud jobbies start working fully (with mic) then it'll all be golden. I am aware that there is quite a lot of stuff involved in that, most of which I don't understand!
Posted Mar 3, 2021 2:42 UTC (Wed)
by Subsentient (guest, #142918)
[Link] (37 responses)
Posted Mar 3, 2021 4:32 UTC (Wed)
by darwi (subscriber, #131202)
[Link] (12 responses)
I had no space left in the article to further expand on this, so I'll write it here: breaking users audio was not always PulseAudio's fault. It was the first heavy user of a certain class of ALSA APIs like audio buffer rewinding; e.g., snd_pcm_rewind() and friends. The proprietary Adobe flash plugin, prevalent back then, also caused its own unique set of problems.
Nonetheless, yes, PulseAudio (and especially its glitch-free support) was pushed too early on users. "I'll break your audio", the constant tongue-in-cheek remark by PulseAudio's lead developer back then, did not also always help. Humility, and some sympathy for users with broken audio setups, were definitely lacking.
The good news is that the community as a whole learned a lot from the ALSA→PulseAudio transition fiasco. Remember that everyone is also more than a decade older now… Everyone is (hopefully) a little-bit wiser.
By the way, the PipeWire developers are keenly aware of the previous audio API transition issues. This was discussed at length in the PipeWire 2018 hackfest: an adults-in-the-room orderly PulseAudio→PipeWire transition was planned early-on. I'm personally optimistic :) [Famous last words?]
Posted Mar 3, 2021 4:48 UTC (Wed)
by Subsentient (guest, #142918)
[Link] (2 responses)
Posted Mar 4, 2021 6:12 UTC (Thu)
by darwi (subscriber, #131202)
[Link]
Posting an empty comment that is just a link to a GIF meme does not contribute to a healthy discussion. Assuming that you were posting in good faith, then the answer is yes, I do (based on interactions with a lot of active developers across the stack.)
Posted Mar 11, 2021 10:21 UTC (Thu)
by oldtomas (guest, #72579)
[Link]
Posted Mar 3, 2021 13:44 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
It's probably more accurate to say that a _huge_ number of ALSA and application[+library] bugs were uncovered and fixed during the early PA days, and that work continues to pay dividends, making future migrations much easier.
(The main technical reason for the ease of the PA->PW migration is that PA and PW both provide ALSA plugins so that software natively using the ALSA API continues to JustWork, and of course PW provides a drop-in PA library replacement..)
Posted Mar 4, 2021 4:14 UTC (Thu)
by darwi (subscriber, #131202)
[Link] (1 responses)
Yes, of course. I thought this was implied. I meant also "wiser" in the technical sense.
> (The main technical reason for the ease of the PA->PW migration is that PA and PW both provide ALSA plugins so that software natively using the ALSA API continues to JustWork, and of course PW provides a drop-in PA library replacement..)
It's not only about that.
Anyone can implement compatibility layers; e.g., roaraudio reimplements the PulseAudio APIs. On the ALSA compatability side, ALSA plugins are actually the simplest part of the equation: it's usually a single C file with some hundred lines of code + a 10-line configuration file.
As discussed in the article, how PipeWire is internally designed is actually what helps a lot. Don't underestimate how a proper initial rigorous design makes things much smoother at the later adoption and transition stages of any software project. A proper design makes everything "fit into place".
PipeWire design and code is semantically simpler than PulseAudio; in part, because everyone got wiser. Anyone who has worked inside the PulseAudio code base for a while will know what I mean here ;)
Posted Mar 5, 2021 14:22 UTC (Fri)
by ecree (guest, #95790)
[Link]
Sounds like PipeWire may be an example of third-system effect. A good sign.
Posted Mar 3, 2021 16:55 UTC (Wed)
by HenrikH (subscriber, #31152)
[Link] (1 responses)
I'll beg to differ, the only reason that the ALSA drivers where ultimately fixed, that PA became usable and that software started to use PA was that it was pushed out to all users as early as it was. Had it not been done this way then PA would be closer to where Wayland is today and PipeWire would have been decades away in the future.
The real QA for any software projects only comes on the day that you get it pushed to end users, it doesn't matter how much internal QA you have done.
Posted Mar 4, 2021 21:26 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
There's always an infinite supply of bugs. If you ever run out of them, just test harder and you will get more. It's a continuum.
Once you ran out of sensible use cases, pass it on to a security team.
Posted Mar 5, 2021 7:00 UTC (Fri)
by WolfWings (subscriber, #56790)
[Link] (3 responses)
They REALLY burned bridges with their attitude and flippant responses in a way few understand, and with many ALSA sound card drivers supporting multiple programs attaching at the same time the main 'requirement' for PulseAudio has become moot at this point for simple laptop or desktop audio use.
Posted Mar 6, 2021 1:52 UTC (Sat)
by BirAdam (guest, #132170)
[Link] (2 responses)
Posted Mar 3, 2021 8:52 UTC (Wed)
by chris_se (subscriber, #99706)
[Link] (19 responses)
I'd like to disagree here. I don't love PulseAudio, but with PulseAudio it was the first time I actually got audio working somewhat reliably on Linux. Previously audio was always a real pain, and it never worked reliably at all. I remember bare OSS, bare ALSA, and even such things as aRts. I always spent a long time trying to get it to work somehow, and then some application came along that didn't work with the setup and I had to figure stuff out again. Note that I'm the opposite of an audiophile, my only requirements are that the sound comes out of the device I want it to, that I can dynamically plug in a head set, that I can adjust the volume, there are no cracks due to buffer underruns, that multiple applications can output audio at the same time, and that I can change settings easily via GUI. I don't think these requirements are particularly onerous (I don't even care about stereo audio, I'd be more than happy with mono), but pre PulseAudio I was never even able to achieve even these basic things. Once PulseAudio came, the first couple of releases it wasn't great, but no worse than my prior experience -- but after a while it actually became reliable. It was the first time I could actually use a Bluetooth headset. (I experimented back when support first appeared in the audio stack before PulseAudio, and that barely worked at all.) Sure, some things still didn't work quite as well as I'd hoped, and there are some issues, but for me PulseAudio was a major improvement compared to everything that came before it. I think PulseAudio has a reputation that is worse than it deserves by a long shot. That said, PipeWire does sound extremely promising, and I'm very excited to try it out at some point when I can find some time, because I do sometimes bump into some of the warts of PulseAudio.
Posted Mar 3, 2021 13:14 UTC (Wed)
by ms-tg (subscriber, #89231)
[Link] (17 responses)
PulseAudio was a huge improvement for me over what came before. Am I misremembering, or wasn’t the prior state that we would have apps crash with “could not open ...” if two apps were trying to make sound at once?
Posted Mar 3, 2021 13:26 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Followed by trying to figure out exactly what application was holding the sound card open. Or zombified sound mixing daemon, of which there were several.
(Unless you were one of the fortunate few to have a sound card that could natively handle multiple simultaneous streams!)
Still, even in its early days, PA was a _huge_ net improvement, and most of the issues that folks attributed to PA were really bugs in the underlying device drivers or applications themselves. (I recall the flash plugin being one of the worst offenders..)
(Something similar played out with NetworkManager/wpa_supplicant and wifi devices that didn't implement the WEXT APIs consistently, and/or applications that were written expecting the quirks of a single driver to apply everywhere)
Posted Mar 3, 2021 15:47 UTC (Wed)
by chris_se (subscriber, #99706)
[Link] (7 responses)
All of the other "sound servers", such as aRts and ESD, were created just for this reason. For programs that weren't compatible with them (basically anything not KDE / not GNOME) you had to start them with a wrapper that used a LD_PRELOAD library to hijack the system calls to open the ALSA/OSS devices, and reroute that through aRts/ESD -- but that didn't work with all software, so you had to kill the sound servers sometimes to use some applications. And then others using the sound server would misbehave. And don't get me started with Suspend-to-RAM, which typically killed any application that was currently outputting audio when closing your laptop lid...
I do remember ALSA having native software mixing, but from what I recall it required all applications to use the same sample rate for their audio, which of course was often not really the case. (Maybe that's changed in the mean time?) And you had to configure it manually in your ~/.asoundrc. Also, I don't know exact time this was added, but I remember seeing ALSA software mixing for the first time when PulseAudio was already a thing, so maybe it came way too late. Or at the very least it wasn't advertised very well, because I didn't read about it before I was already switching to PulseAudio.
Posted Mar 3, 2021 19:32 UTC (Wed)
by dezgeg (subscriber, #92243)
[Link] (5 responses)
However this was long time (years) ago, definitely before me owning any USB or Bluetooth exclusive audio devices. I do not even remember when "killall pulseaudio" last solved anything And regardless of that being able to adjust sound levels per-application with PA has been very useful (lack of it is not show stopper but just very nice to have).
Posted Mar 4, 2021 4:52 UTC (Thu)
by jeltz (guest, #88600)
[Link] (2 responses)
Posted Mar 5, 2021 0:06 UTC (Fri)
by hailfinger (subscriber, #76962)
[Link] (1 responses)
PipeWire seems to care about not breaking existing setups and the article implies that the community is nice. I'm happy about that and look forward to testing it.
Posted Mar 5, 2021 5:56 UTC (Fri)
by zdzichu (subscriber, #17118)
[Link]
Posted Mar 4, 2021 15:45 UTC (Thu)
by sorpigal (guest, #36106)
[Link] (1 responses)
The only thing I occasionally pine for is per-process volume control.
Posted Mar 18, 2021 9:20 UTC (Thu)
by mgedmin (subscriber, #34497)
[Link]
Posted Mar 17, 2021 10:18 UTC (Wed)
by immibis (subscriber, #105511)
[Link]
Posted Mar 7, 2021 9:23 UTC (Sun)
by jengelh (guest, #33263)
[Link] (6 responses)
Quite the contrary. People had actual proper soundcards (me: ad1816 or cs46xx on daughterboards), and with other chips (me: ali5451 in first post-2000 laptop), there was ALSA's dmix that would do software mixing via shared memory, before moving the software mixing off to separate - and quite high latency! - daemons like PA.
Posted Mar 7, 2021 12:44 UTC (Sun)
by pizza (subscriber, #46)
[Link] (5 responses)
Just because you had high-end audio gear (for the time) doesn't mean most folks did. Even before Intel standardized onboard audio with the bog-simple single-stream AC97 spec, the overwhelming majority of the audio chips on the market only supported a single hardware PCM stream. Multi-stream hardware was always the upper echelon of the market.
> there was ALSA's dmix that would do software mixing via shared memory
I recall having a lot of issues with dmix in its early days. Not surprising as the same sorts of driver/library/application bugs that made PA a bit rocky also affected dmix.
Posted Mar 7, 2021 15:15 UTC (Sun)
by jengelh (guest, #33263)
[Link] (1 responses)
I never thought of the two being particular high-end; ad1816 came with the package, the cs46xx was a 20€ second-hand thing.
Posted Mar 10, 2021 3:28 UTC (Wed)
by pizza (subscriber, #46)
[Link]
(I owned a high-end CS4630 device in the late 2000 timeframe, mainly because it had drivers that were stable on the multiprocessor Win2K system that I was using for realtime video capture. I ended up selling it after that project was over due to zero Linux support..)
I stand corrected on the AD1816; a quick bit of research shows that supports six simultaneous streams mixed onto two output channels, although given its ISA nature it seems unlikely to achieve that with "CD quality" audio, and seems to have been sold nearly exclusively on bare-minimum cards as a super cheap way to met Microsoft's "MPC97" spec.
But yeah, these were both considerably more capable (at a chipset level) than most of their contemporaries. Until you pointed out the AD1816 I wasn't aware that any mainstream multi-stream ISA cards existed, and the PCI cards of that era tended to be the cheap bare-minimum crap that pretty much ended once onboard AC97 audio came along, leaving just the higher-end stuff targeted at gamers wanting to take advantage of native multi-stream 3D positional audio.
The market for all of this fancy stuff evaporated pretty quickly after Microsoft removed support for hardware-based multi-stream (and 3D positional) audio with Vista -- Despite the spec allowing for it, I don't know offhand of any "HD Audio" controller that implements multi-stream mixing; instead it's one stream per external audio codec. There may be more than one codec (ie two 2-channel codecs instead of one 4-channel codec) but that's pretty rare.
(Of course, pro audio hardware still exists, but those are nearly always single-stream-per-channel and rely on the CPU for mixing/dsp work, but specialized hardware can do whatever it wants, of course..)
Posted Mar 8, 2021 14:21 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
Never had a problem with dmix.
Posted Mar 9, 2021 16:39 UTC (Tue)
by zlynx (guest, #2285)
[Link] (1 responses)
Back when I ran Gentoo Linux I did run ALSA with dmix. And I did have problems sometimes. For example, if you nice some process which is acting as the dmix output to ALSA it gets under runs. If a process which is part of dmix gets hammered by OOM or a kill -9 signal things can get super messed up.
The best setup was on my home desktop running Gentoo because there I had a Soundblaster Audigy 2 card which managed a full 5.1 surround setup and I believe 16 independent input sources. The only real problem there was alsactl which had about 500 cryptically named visible controls.
Posted Mar 9, 2021 17:32 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Mar 15, 2021 6:10 UTC (Mon)
by flussence (guest, #85566)
[Link]
Posted Mar 4, 2021 7:42 UTC (Thu)
by josh (subscriber, #17465)
[Link]
Posted Mar 3, 2021 21:49 UTC (Wed)
by ncm (guest, #165)
[Link] (3 responses)
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.
Posted Mar 3, 2021 22:35 UTC (Wed)
by pebolle (guest, #35204)
[Link] (2 responses)
Please speak for yourself.
Posted Mar 4, 2021 3:55 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
It wasn't that hard to fix, but still.
Posted Mar 4, 2021 9:51 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
PulseAudio relied on the underlying layers working properly. For the most part, at the time, they didn't.
Cheers,
Posted Mar 3, 2021 9:38 UTC (Wed)
by zuki (subscriber, #41808)
[Link] (1 responses)
Posted Mar 4, 2021 10:06 UTC (Thu)
by mordae (guest, #54701)
[Link]
Posted Mar 4, 2021 8:31 UTC (Thu)
by andreashappe (subscriber, #4810)
[Link] (1 responses)
Problem is made even "funnier" as my laptop is sometimes plugged into a docking station with audio line-out..
Posted Mar 4, 2021 17:01 UTC (Thu)
by busman (subscriber, #7333)
[Link]
Telling Gnome bluetooth settings to forget those devices and then pairing them again fixed all issues. All is well now :)
Posted Mar 3, 2021 9:31 UTC (Wed)
by dottedmag (subscriber, #18590)
[Link]
This is confusing. XML protocol description, not serialization, right?
Posted Mar 3, 2021 10:59 UTC (Wed)
by smcv (subscriber, #53363)
[Link] (6 responses)
The ability to use PipeWire to replace the other audio services didn't arrive at a great time for the Debian 11 release cycle - in the versions that were available at freeze time, it can be made to work, but didn't seem mature enough to support for 2 years with minimal changes. The packaging is set up to make it possible, but making it straightforward without introducing regressions will need help from domain experts.
The maintainer-of-record for Debian's PipeWire packaging has been busy with other things, so the 0.2 -> 0.3 transition had to be done by other contributors (such as me) in order to keep screen sharing and screencasting working in GNOME, and I wouldn't feel comfortable pushing forward a transition to PipeWire for audio on its current level of maintainer bandwidth.
I suspect PipeWire for audio might become the recommendation in the Debian 12 cycle if more knowledgeable maintainers step in.
Posted Mar 3, 2021 21:19 UTC (Wed)
by paravoid (subscriber, #32869)
[Link] (3 responses)
Posted Mar 4, 2021 4:48 UTC (Thu)
by simcop2387 (subscriber, #101710)
[Link]
Posted Mar 4, 2021 13:44 UTC (Thu)
by smcv (subscriber, #53363)
[Link] (1 responses)
However, *I* don't understand the pipewire code well enough to be the one justifying to the release team why we need any particular change, and it still seems to be at the stage of maturity where targeted bug fixes, higher-regression-risk feature work, and harder-to-review refactoring/restructuring are mixed into one stream of commits; so I don't feel comfortable treating it like I would treat a bugfix-only stable-branch, like (say) GNOME Shell 3.38.x.
Sorry, I've done what I can, and if other people can do a better job then I'll be happy to step out of the way, but I am not the person to make this happen myself.
Posted Mar 4, 2021 17:29 UTC (Thu)
by darwi (subscriber, #131202)
[Link]
The PipeWire commit logs are also very terse, and a lot of times just one-liners with no further context. IMHO, the project should really improve its commit logs from now on, especially that distributions are beginning to adopt it by default.
In fairness, the source code was a real beauty to look at; but the commit logs… not so much.
Posted Mar 8, 2021 6:43 UTC (Mon)
by joib (subscriber, #8541)
[Link] (1 responses)
Thanks for the heads-up, and for your work in this. Hope things get sorted out for Debian 12 and the next Ubuntu LTS (22.04?).
And getting a bit off-topic, this seems to be another example where the Debian "culture" (or what should it be called?) of packages by default being single-maintainer fiefdoms is hurtful to the project and users. Hopefully this can eventually be fixed as well (though I'm not holding my breath).
Posted Mar 9, 2021 18:29 UTC (Tue)
by emorrp1 (guest, #99512)
[Link]
This graph shows pretty clearly that the fiefdom culture is now largely an historical artifact, but ultimately everything relies on volunteers, and therefore interest/buy-in from someone other than the initial uploader.
Posted Mar 3, 2021 15:07 UTC (Wed)
by clump (subscriber, #27801)
[Link] (7 responses)
Some of the early discussion on Linux Musicians is promising, however: https://linuxmusicians.com/viewtopic.php?f=27&t=22150
Posted Mar 3, 2021 17:43 UTC (Wed)
by jsmith45 (guest, #125263)
[Link] (4 responses)
Posted Mar 3, 2021 20:22 UTC (Wed)
by andresfreund (subscriber, #69562)
[Link]
Posted Mar 3, 2021 22:16 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Mar 3, 2021 23:24 UTC (Wed)
by nyanpasu64 (guest, #135579)
[Link] (1 responses)
Additionally, looking at https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ (which may or may not be up-to-date):
- "Does Desktop Audio Interfere With Pro-Audio Using PipeWire?" talks as if they haven't picked, implemented, and debugged an approach yet.
> This does not include extra buffering in the resamplers (~50 samples). There is a resampler in each stream and sink/source. There is not yet an option to remove the resampler latency while inactive.
I've experienced audio xruns and high CPU usage (possibly linked to Pipewire) when attempting to use Pipewire's Pulse API on my laptop (Pipewire 0.3 non-Git on Arch Linux, a few weeks ago) (though without a realtime kernel). Maybe my system can't handle the latency I picked, though I forgot what it was. I ended up erasing/resetting my Pipewire config files, when debugging Pipewire causing Minecraft and Telegram Desktop to hang upon startup.
Posted Mar 4, 2021 5:47 UTC (Thu)
by darwi (subscriber, #131202)
[Link]
No, that's an artifact of NixOS building QjackCtl in an obsolete manner. QjackCtl works out of the box with PipeWire, in both Arch Linux and Fedora (didn't try other distributions).
Posted Mar 3, 2021 18:17 UTC (Wed)
by dbnichol (subscriber, #39622)
[Link] (1 responses)
Posted Mar 4, 2021 6:05 UTC (Thu)
by darwi (subscriber, #131202)
[Link]
Indeed. Check this cool PipeWire audio pipeline. It shows Carla, a JACK application, controlling the audio pipeline routing of multiple PulseAudio applications like Firefox, and GNOME Settings. It also shows Spotify, a PulseAudio application, having its audio streams passed through Calf Bass Enhancer, a JACK plugin, then routed to the system's default ALSA sink.
Posted Mar 3, 2021 18:18 UTC (Wed)
by dancol (guest, #142293)
[Link] (4 responses)
Posted Mar 3, 2021 20:57 UTC (Wed)
by josh (subscriber, #17465)
[Link]
Someone just needs to take this upstream with a patch and clear justification.
Posted Mar 4, 2021 16:06 UTC (Thu)
by floppus (guest, #137245)
[Link] (2 responses)
Difficult to see how you could avoid that without requiring applications to opt-in to a higher limit... which is what distros seem to be doing lately, by increasing the hard limit to 262144 or 1048576, while leaving the soft limit at 1024.
Posted Mar 4, 2021 21:39 UTC (Thu)
by zuki (subscriber, #41808)
[Link] (1 responses)
> The Linux kernel's current default RLIMIT_NOFILE resource limit for userspace processes is set to 1024 (soft) and 4096 (hard). Previously, systemd passed this on unmodified to all processes it forked off. With this systemd release the hard limit systemd passes on is increased to 512K, overriding the kernel's defaults and substantially increasing the number of simultaneous file descriptors unprivileged userspace processes can allocate. Note that the soft limit remains at 1024 for compatibility reasons: the traditional UNIX select() call cannot deal with file descriptors >= 1024 and increasing the soft limit globally might thus result in programs unexpectedly allocating a high file descriptor and thus failing abnormally when attempting to use it with select() (of course, programs shouldn't use select() anymore, and prefer poll()/epoll, but the call unfortunately remains undeservedly popular at this time). This change reflects the fact that file descriptor handling in the Linux kernel has been optimized in more recent kernels and allocating large numbers of them should be much cheaper both in memory and in performance than it used to be. Programs that want to take benefit of the increased limit have to "opt-in" into high file descriptors explicitly by raising their soft limit. Of course, when they do that they must acknowledge that they cannot use select() anymore (and neither can any shared library they use — or any shared library used by any shared library they use and so on). Which default hard limit is most appropriate is of course hard to decide. However, given reports that ~300K file descriptors are used in real-life applications we believe 512K is sufficiently high as new default for now. Note that there are also reports that using very high hard limits (e.g. 1G) is problematic: some software allocates large arrays with one element for each potential file descriptor (Java, …) — a high hard limit thus triggers excessively large memory allocations in these applications. Hopefully, the new default of 512K is a good middle ground: higher than what real-life applications currently need, and low enough for avoid triggering excessively large allocations in problematic software. (And yes, somebody should fix Java.)
Posted Mar 6, 2021 1:01 UTC (Sat)
by plugwash (subscriber, #29694)
[Link]
Posted Mar 3, 2021 19:33 UTC (Wed)
by g2boojum (subscriber, #152)
[Link]
Posted Mar 3, 2021 20:28 UTC (Wed)
by jafd (subscriber, #129642)
[Link] (1 responses)
Does it mean that if I switch to Pipewire now, I’m going to lose this, because Pipewire audio cannot into network?
On that note, can Pipewire and PulseAudio run side by side (using, say, different sockets) with Pulse handling the AirPlay stuff and Pipewire piping audio to it as needed?
Posted Mar 3, 2021 22:50 UTC (Wed)
by flussence (guest, #85566)
[Link]
In the meantime, if PW can be told to spin up a Pulse compatibility network socket on localhost (I haven't looked into it, but I know it has *some* PA emulation) then you can use that for duplex audio as you would from a networked Pulse daemon. Be warned though that Pulse will choke badly on latency in the audio routing layer, so minimise how many physical network hops it uses. Learned that the hard way.
Posted Mar 3, 2021 23:16 UTC (Wed)
by vinipsmaker (guest, #126735)
[Link] (2 responses)
Does anyone know of its author?
Posted Mar 4, 2021 13:55 UTC (Thu)
by lkundrak (subscriber, #43452)
[Link] (1 responses)
Posted Mar 15, 2021 6:41 UTC (Mon)
by flussence (guest, #85566)
[Link]
Posted Mar 4, 2021 16:12 UTC (Thu)
by vstarwalt (subscriber, #98529)
[Link]
Posted Mar 10, 2021 6:25 UTC (Wed)
by ghane (guest, #1805)
[Link] (3 responses)
I am running ubuntu/hirsute on my laptop (which will become 21.04), and I see
pipewire/hirsute,now 0.3.22-2 amd64 [installed,automatic]
How can I check if I am using it? I see pulseaudio packages installed as well, FWIW.
--
Posted Mar 14, 2021 13:24 UTC (Sun)
by Hi-Angel (guest, #110915)
[Link]
Posted Mar 17, 2021 17:08 UTC (Wed)
by darwi (subscriber, #131202)
[Link] (1 responses)
In your Ubuntu 21.04 setup, PipeWire is only used for camera multiplexing and Wayland screen sharing. It is not used for routing audio. This is why you still have the PulseAudio package installed, and enabled, by default.
Posted Mar 18, 2021 12:13 UTC (Thu)
by ghane (guest, #1805)
[Link]
I can confirm that both pulseaudio and pipewire are running, as systemd user services.
Thanks
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/co...
Please don't ask for Chromecast anywhere
Please don't ask for Chromecast anywhere
Please don't ask for Chromecast anywhere
Please don't ask for Chromecast anywhere
Please don't ask for Chromecast anywhere
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
I don't want to be out of luck for fixing broken shit for the next 3 years while the world gets used to PipeWire.
PipeWire: The Linux audio/video bus
>Remember that everyone is also more than a decade older now… Everyone is (hopefully) a little-bit wiser.
PipeWire: The Linux audio/video bus
You think so?
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
Nobody liked Pulseaudio
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
If you do not report bugs, they won't be fixed. And you will have the same problem with pipewire.
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
Wol
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
- bluetooth daemon crashed 3 times
- external headphones and speakers were available in Gnome Settings but no sound and when I tried to test them there were no left or right speaker to push in the dialog
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
Well it is part of the Utopia team, otherwise smcv would have had to go via NMUs, but that does seem to be a very loose collection of desktop software. Some teams do make deliberate effort to upload each others packages (IIRC started by debian-med advertising team graphs), others contribute but tend to let the primary uploader do their thing.
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
Wol
PipeWire: The Linux audio/video bus
- I hope they remove it before 1.0.
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
KLANG
KLANG
Thank you!
KLANG
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
Sanjeev
I imagine you will not have a pulseaudio process running, i.e. executing
PipeWire: The Linux audio/video bus
will not give you a pulseaudio process, similar to the output I here.
Also, usually pulseaudio is enabled as a "user" systemd service. I imagine, it might be different depending on a distro, but at least on Archlinux I can check on it as:
λ ps aux | grep pulseaudio
constan+ 610 1.4 0.1 3120980 14064 ? Ssl мар10 80:22 /usr/bin/pulseaudio --daemonize=no --log-target=journal
λ systemctl status --user pulseaudio
● pulseaudio.service - Sound Service
Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-03-10 21:45:01 MSK; 3 days ago
TriggeredBy: ● pulseaudio.socket
Main PID: 610 (pulseaudio)
Tasks: 7 (limit: 9392)
Memory: 14.4M
CPU: 1h 20min 22.968s
CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/pulseaudio.service
├─610 /usr/bin/pulseaudio --daemonize=no --log-target=journal
└─704 /usr/lib/pulse/gsettings-helper
мар 10 21:44:51 constantine-N61Ja systemd[602]: Starting Sound Service...
мар 10 21:45:01 constantine-N61Ja systemd[602]: Started Sound Service.
мар 10 21:45:02 constantine-N61Ja pulseaudio[610]: Found duplicated D-Bus path for adapter /org/bluez/hci0
мар 10 21:45:02 constantine-N61Ja pulseaudio[610]: Found duplicated D-Bus path for device /org/bluez/hci0/dev_78_A7_EB_7A_3D_E2
мар 10 21:45:02 constantine-N61Ja pulseaudio[610]: Found duplicated D-Bus path for device /org/bluez/hci0/dev_41_42_51_CD_29_12
PipeWire: The Linux audio/video bus
PipeWire: The Linux audio/video bus
