|
|
Subscribe / Log in / New account

PipeWire: The Linux audio/video bus

March 2, 2021

This article was contributed by Ahmed S. Darwish

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]

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
GuestArticlesDarwish, Ahmed S.


to post comments

PipeWire: The Linux audio/video bus

Posted Mar 2, 2021 21:55 UTC (Tue) by josh (subscriber, #17465) [Link] (12 responses)

Is anyone aware of any plans to support Chromecast devices in Pipewire? I'd love to be able to route playing audio or video to a TV.

PipeWire: The Linux audio/video bus

Posted Mar 2, 2021 23:14 UTC (Tue) by tchernobog (guest, #73595) [Link] (2 responses)

I am not sure encoding and network playback is a goal for Pipewire on its own. Maybe through gstreamer?

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 0:29 UTC (Wed) by josh (subscriber, #17465) [Link] (1 responses)

I wouldn't expect it to be directly in Pipewire; rather, it'd be nice to have a Pipewire output sink that could stream audio and video to a device, with Pipewire handling low-latency provision of data, and the output sink doing hardware-accelerated encoding and streaming.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 21:29 UTC (Wed) by westurner (guest, #145208) [Link]

How could mkchromecast most optimally include support for PipeWire?

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.

https://github.com/topics/chromecast

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 16:22 UTC (Wed) by NightMonkey (subscriber, #23051) [Link] (3 responses)

For my use-case (my home network, HiFiBerry Analogue to Digital converters, Raspberry Pis with USB Digital-to-Analogue converters, and analogue audio playback setups), the network audio slinging capability is actually my favorite part of PulseAudio. :) I do hope that use-case gets even more robust with PipeWire. The way PulseAudio seems to magically keep video and audio in sync when playing video locally but directing the audio over a WiFi network is impressive. (Even SnapCast can't do that, but it wasn't built to handle video/audio synchronization.) Cheers!

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 14:42 UTC (Thu) by mgedmin (subscriber, #34497) [Link] (2 responses)

Ooh, it works nowadays? I tried PA's network audio support exactly once, 15 years ago, and was disappointed to get short pauses exactly 2 minutes apart.

(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.)

PipeWire: The Linux audio/video bus

Posted Mar 5, 2021 8:11 UTC (Fri) by lathiat (subscriber, #18567) [Link]

15 years ago was March 2006. The first PulseAudio release was July 2004. Ubuntu shipped it by default in 2008.

Safe to say it might be worth trying again ;)

PipeWire: The Linux audio/video bus

Posted Mar 13, 2021 13:24 UTC (Sat) by mkbosmans (subscriber, #65556) [Link]

Ah, that brings back some memories!

Yes, I think some of those problems were fixed about 10 years ago, with this commit and some of its parents:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/co...

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.

Please don't ask for Chromecast anywhere

Posted Mar 3, 2021 18:10 UTC (Wed) by fratti (guest, #105722) [Link] (4 responses)

Support a proprietary undocumented protocol that requires loading a Google-controlled web page and is merely a glorified backdoored HLS streaming server? Why that sounds grand, please repeatedly request it on the mpv issue tracker as well.

Please don't ask for Chromecast anywhere

Posted Mar 3, 2021 20:52 UTC (Wed) by josh (subscriber, #17465) [Link] (3 responses)

I'm sorry to hear that you've had issues with unhelpful or overly expectant bug reports. Please don't project that onto everyone who's interested in seeing two technologies to work together.

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.

Please don't ask for Chromecast anywhere

Posted Mar 4, 2021 8:28 UTC (Thu) by andreashappe (subscriber, #4810) [Link] (2 responses)

..given this response, I am again reminded why I use an "early" lwn-subscriber number as "niceness-indicator".

Please don't ask for Chromecast anywhere

Posted Mar 14, 2021 3:59 UTC (Sun) by calumapplepie (guest, #143655) [Link]

*cries in sextuple-digit account number*

Please don't ask for Chromecast anywhere

Posted Mar 14, 2021 4:47 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

KILL ALL HUMANS! ROBOTS RULE!

Hey, it seems to be working!

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 2:03 UTC (Wed) by gerdesj (subscriber, #5446) [Link] (42 responses)

This: https://bugzilla.redhat.com/show_bug.cgi?id=1906086 is quite devoid of complete meltdown which is a good sign.

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!

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 2:42 UTC (Wed) by Subsentient (subscriber, #142918) [Link] (37 responses)

Nobody liked Pulseaudio, but I hope the transition here goes a whole lot smoother than the ALSA to Pulseaudio one did.
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

Posted Mar 3, 2021 4:32 UTC (Wed) by darwi (subscriber, #131202) [Link] (12 responses)

> Nobody liked Pulseaudio, but I hope the transition here goes a whole lot smoother than the ALSA to Pulseaudio one did.

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?]

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 4:48 UTC (Wed) by Subsentient (subscriber, #142918) [Link] (2 responses)

>Remember that everyone is also more than a decade older now… Everyone is (hopefully) a little-bit wiser.

You think so?

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 6:12 UTC (Thu) by darwi (subscriber, #131202) [Link]

> You think so?

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.)

PipeWire: The Linux audio/video bus

Posted Mar 11, 2021 10:21 UTC (Thu) by oldtomas (guest, #72579) [Link]

Besides, your link wants me to "do" some javascript to see the gif. My browser was too lazy, so I didn't see anything. Perhaps I'm glad I didn't :-P

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 13:44 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> 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

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..)

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 4:14 UTC (Thu) by darwi (subscriber, #131202) [Link] (1 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.

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 ;)

PipeWire: The Linux audio/video bus

Posted Mar 5, 2021 14:22 UTC (Fri) by ecree (guest, #95790) [Link]

> PipeWire design and code is semantically simpler than PulseAudio; in part, because everyone got wiser.

Sounds like PipeWire may be an example of third-system effect. A good sign.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 16:55 UTC (Wed) by HenrikH (subscriber, #31152) [Link] (1 responses)

> Nonetheless, yes, PulseAudio (and especially its glitch-free support) was pushed too early on users

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.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 21:26 UTC (Thu) by marcH (subscriber, #57642) [Link]

> 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.

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.

PipeWire: The Linux audio/video bus

Posted Mar 5, 2021 7:00 UTC (Fri) by WolfWings (subscriber, #56790) [Link] (3 responses)

I'll be honest, PulseAudio headaches kept being so bad and responses soured me so hard on the platform that I'm still using native ALSA instead with PulseAudio not even installed at all on my systems.

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.

PipeWire: The Linux audio/video bus

Posted Mar 6, 2021 1:52 UTC (Sat) by BirAdam (guest, #132170) [Link] (2 responses)

I actually use OSS4. I was mad enough with ALSA’s release, and then Pulse came out and OSS had been fixed in the mean time so I went back.

PipeWire: The Linux audio/video bus

Posted Mar 6, 2021 1:58 UTC (Sat) by pabs (subscriber, #43278) [Link] (1 responses)

Is OSS4 still developed?

PipeWire: The Linux audio/video bus

Posted Mar 6, 2021 5:22 UTC (Sat) by BirAdam (guest, #132170) [Link]

Indeed. Yes.

http://opensound.com/

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 8:52 UTC (Wed) by chris_se (subscriber, #99706) [Link] (19 responses)

Nobody liked Pulseaudio

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.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 13:14 UTC (Wed) by ms-tg (subscriber, #89231) [Link] (17 responses)

I wonder how we are culturally at the point that it seems worth the time to write a comment simply to agree that I shared this experience.

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?

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 13:26 UTC (Wed) by pizza (subscriber, #46) [Link]

> 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?

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)

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 15:47 UTC (Wed) by chris_se (subscriber, #99706) [Link] (7 responses)

> 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?

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.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 19:32 UTC (Wed) by dezgeg (subscriber, #92243) [Link] (5 responses)

At least my personal recollection is that there was a period where ALSA software mixing (without any tweaking of .asoundrc or anything on most distros) was working very well, better than PulseAudio - as in, many audio problems could be solved by a "killall pulseaudio" (I do not remember if root was required for this or not).

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).

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 4:52 UTC (Thu) by jeltz (guest, #88600) [Link] (2 responses)

I still have to solve audio problems by killing PuleAudio (last time I did it was about 2 weeks ago), and as far as I know it coul always be done without superuser privileges. I am one of the minority who never have experienced PulseAudio becoming stable, it is better than ti was when I first used it but still quite unstable.

PipeWire: The Linux audio/video bus

Posted Mar 5, 2021 0:06 UTC (Fri) by hailfinger (subscriber, #76962) [Link] (1 responses)

Killing/restarting pulseaudio (pulseaudio -k) after a suspend-to-RAM is required and sufficient to get my USB webcam microphone working again in ~90% of my suspend cycles. That's a few times per day. I didn't bother reporting that because I've seen too many pulseaudio bug reports being dismissed along the lines of "pulseaudio is never buggy, it's the fault of your driver/application/whatever".

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.

PipeWire: The Linux audio/video bus

Posted Mar 5, 2021 5:56 UTC (Fri) by zdzichu (subscriber, #17118) [Link]

Not to defend PA, but it really smells like USB microphone driver problem. It seem not to handle suspend/resume cycle (while device is opened?).
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

Posted Mar 4, 2021 15:45 UTC (Thu) by sorpigal (guest, #36106) [Link] (1 responses)

For whatever it's worth I still run purely ALSA with software mixing, including things like USB audio devices (just added a new mic yesterday), multiple applications playing audio at the same time, and everything Just Works with no issues. I do have a .asoundrc, but it's pretty boilerplate and I haven't had to change it in years. The only time I have audio trouble is when I need to run a program that only supports pulse (but there's apulse for that).

The only thing I occasionally pine for is per-process volume control.

PipeWire: The Linux audio/video bus

Posted Mar 18, 2021 9:20 UTC (Thu) by mgedmin (subscriber, #34497) [Link]

Is pure ALSA able to move a playing stream from one device to another (say, internal speakers to a Bluetooth headset)?

PipeWire: The Linux audio/video bus

Posted Mar 17, 2021 10:18 UTC (Wed) by immibis (subscriber, #105511) [Link]

I am not sure how things were "back then", but ALSA today has both rate conversion and mixing plugins. If you layer those in the right order, applications can output at different rates. Whether the default configuration does this or not is a different question.

PipeWire: The Linux audio/video bus

Posted Mar 7, 2021 9:23 UTC (Sun) by jengelh (guest, #33263) [Link] (6 responses)

>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?

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.

PipeWire: The Linux audio/video bus

Posted Mar 7, 2021 12:44 UTC (Sun) by pizza (subscriber, #46) [Link] (5 responses)

> Quite the contrary. People had actual proper soundcards (me: ad1816 or cs46xx on daughterboards),

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.

PipeWire: The Linux audio/video bus

Posted Mar 7, 2021 15:15 UTC (Sun) by jengelh (guest, #33263) [Link] (1 responses)

>Just because you had high-end audio gear

I never thought of the two being particular high-end; ad1816 came with the package, the cs46xx was a 20€ second-hand thing.

PipeWire: The Linux audio/video bus

Posted Mar 10, 2021 3:28 UTC (Wed) by pizza (subscriber, #46) [Link]

The cs46xx series were multi-channel, multi-stream DSP-based 3d-positional-audio-capable controllers that were roughly comparable in capabilities to the Sound Blaster Live series.

(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..)

PipeWire: The Linux audio/video bus

Posted Mar 8, 2021 14:21 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (2 responses)

ALSA dmix is still there, it works fine. I've used it for years since I don't use pulseaudio because it's unpredictable and I don't feel like doing debug every time it fails.

Never had a problem with dmix.

PipeWire: The Linux audio/video bus

Posted Mar 9, 2021 16:39 UTC (Tue) by zlynx (guest, #2285) [Link] (1 responses)

People can say that about Pulseaudio too. Never had problems with it. Or not serious ones anyway. Yes, I have had it glitch and flip off USB headphones back to speakers or other things. But nothing seriously wrong.

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.

PipeWire: The Linux audio/video bus

Posted Mar 9, 2021 17:32 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Ah, I remember trying to find the right things to mute/unmute in ALSA's mixer even with a simple laptop setup. Many unfun times when you need to do it on a quick turn around time.

PipeWire: The Linux audio/video bus

Posted Mar 15, 2021 6:10 UTC (Mon) by flussence (guest, #85566) [Link]

For me it was that apps using sound would hang and require a `kill -9` if I dared use suspend-to-ram - the sound card driver itself was broken and required a rmmod/modprobe across suspends to fix. PulseAudio let me work around that, all I had to do was wrap the system suspend in pasuspender.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 7:42 UTC (Thu) by josh (subscriber, #17465) [Link]

This was my experience as well. The ability to dynamically change where audio goes, to send it to a Bluetooth device or stream it over a network, without restarting applications? I was extremely impressed at the time.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 21:49 UTC (Wed) by ncm (guest, #165) [Link] (3 responses)

Everybody had trouble with PA, 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.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 22:35 UTC (Wed) by pebolle (guest, #35204) [Link] (2 responses)

> Everybody had trouble with PA, even people who liked it in principle.

Please speak for yourself.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 3:55 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

ncm's statement is a bit of a hyperbole, but only a bit. Early PA had broken even the most basic setups that used bog-standard Intel sound chips.

It wasn't that hard to fix, but still.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 9:51 UTC (Thu) by Wol (subscriber, #4433) [Link]

Setups that only worked because the user had tweaked OSS, ALSA etc to ****ery to force them to work ...

PulseAudio relied on the underlying layers working properly. For the most part, at the time, they didn't.

Cheers,
Wol

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 9:38 UTC (Wed) by zuki (subscriber, #41808) [Link] (1 responses)

Yep. It seems to be going surprisingly smoothly in F34 beta. Issues that are being seen are mostly related to bluetooth — and bluetooth support was always a bit iffy. Often it's not even clear if pipewire is relevant at all, or if changes in bluez or the kernel are the cause. The overall feeling I get from my testing and what other people report is that things at this point are running just as well as with pulseaudio or marginally better.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 10:06 UTC (Thu) by mordae (guest, #54701) [Link]

Thanks for the heads up. My wife would be sad if Bluetooth headset did not work with our HTPC.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 8:31 UTC (Thu) by andreashappe (subscriber, #4810) [Link] (1 responses)

any experience with bluetooth integration? Currently running on pulseaudio/fedora and I do have lots of weird stuff going on with a bluetooth headset and browser-based video conferencing software. Don't know why, but sometimes I need to restart the webbrowser to get the bluetooth headset working (even when pulseaudio shows that it should be used as audiosink).

Problem is made even "funnier" as my laptop is sometimes plugged into a docking station with audio line-out..

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 17:01 UTC (Thu) by busman (subscriber, #7333) [Link]

Inspired by this article I migrated from Pulseaudio to Pipewire yesterday. In the beginning I had weird bluetooth issues

- 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

Telling Gnome bluetooth settings to forget those devices and then pairing them again fixed all issues. All is well now :)

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 9:31 UTC (Wed) by dottedmag (subscriber, #18590) [Link]

> XML serialization part

This is confusing. XML protocol description, not serialization, right?

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 10:59 UTC (Wed) by smcv (subscriber, #53363) [Link] (6 responses)

> Debian offers PipeWire packages, but replacing PulseAudio or JACK is "an unsupported use case."

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.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 21:19 UTC (Wed) by paravoid (subscriber, #32869) [Link] (3 responses)

Thank you so much for all of the efforts here :) The timing is indeed unfortunate! It's kind of a pity that we're missing all the 0.3.{20,21,22} improvements though (AIUI Fedora will release with .22). Perhaps it would be worth asking the Debian release team for a freeze exception for 0.3.22 here so that users could at least have the same level of experience as Fedora 34 users by opting in?

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 4:48 UTC (Thu) by simcop2387 (subscriber, #101710) [Link]

This is likely to happen not as a freeze exception but instead as a backport from testing once the release happens. That leaves the known working config in stable and then testing and backports can deal with any lingering issues. It's one reason why I either run testing or backports on my systems (depending on the level of pain I'm willing to deal with at the time).

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 13:44 UTC (Thu) by smcv (subscriber, #53363) [Link] (1 responses)

If you think you can justify each line of diff to the release team, go for it (I'd suggest talking to Sjoerd, who uploaded 0.3.22 to experimental). Or, if there are individual commits that have a low regression risk and high importance, please go ahead.

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.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 17:29 UTC (Thu) by darwi (subscriber, #131202) [Link]

> 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

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.

PipeWire: The Linux audio/video bus

Posted Mar 8, 2021 6:43 UTC (Mon) by joib (subscriber, #8541) [Link] (1 responses)

> I suspect PipeWire for audio might become the recommendation in the Debian 12 cycle if more knowledgeable maintainers step in.

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).

PipeWire: The Linux audio/video bus

Posted Mar 9, 2021 18:29 UTC (Tue) by emorrp1 (guest, #99512) [Link]

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.

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.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 15:07 UTC (Wed) by clump (subscriber, #27801) [Link] (7 responses)

I'd be curious if PipeWire really could replace JACK right now. JACK has been dragged through the ringer to get latency extremely low, for quite a long time. While mentioned in the article, it's not just low latency that a JACK-based workflow enables. JACK's workflow enables extremely flexible signal routing. It's quite easy with command line or GUI tools to take a guitar signal from an external capture device and route it through an effects stack like Guitarix and into a DAW like Ardour. What if you'd like to keep the dry signal at the same time? Simply route the raw signal into a new track in a DAW. What if you want one signal or the other to be played through certain speakers? Simply adjust accordingly in JACK's tools. And so on.

Some of the early discussion on Linux Musicians is promising, however: https://linuxmusicians.com/viewtopic.php?f=27&t=22150

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 17:43 UTC (Wed) by jsmith45 (guest, #125263) [Link] (4 responses)

My understanding is that basically all the routing flexibility of JACK is fully present, and works. From what I've read, not only does it work, but the existing tools you use to manage the JACK graph will let you re-configure the audio graph for PulseAudio API applications too, as though they had magically became JACK apps. This is a very different experience from the nearly impossible to set up PulseAudio over JACK, where you could not configure each individual PulseAudio stream.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 20:22 UTC (Wed) by andresfreund (subscriber, #69562) [Link]

In the bug tracker for pipewire there were people using it for pretty complex jack setups. Seems perf / latency unsurprisingly isn't on par yet, but improving.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 22:16 UTC (Wed) by Wol (subscriber, #4433) [Link]

But that's rather irrelevant. As I understood it, the PRIMARY motivation behind Jack was the minimal latency. If you haven't got that, you won't even be considered as a Jack replacement, whatever else you may offer.

Cheers,
Wol

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 23:24 UTC (Wed) by nyanpasu64 (guest, #135579) [Link] (1 responses)

QjackCtl fails to start on pipewire-jack because qjackctl uses the JACK session API. If you override the .so file (eg. using pipewire-jack-dropin), you get a dynamic linking error when running qjackctl (missing symbol jack_session_commands_free). Fixing this requires rebuilding qjackctl without the deprecated session API (https://github.com/NixOS/nixpkgs/issues/102547#issuecomme...).

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 hope they remove it before 1.0.

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.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 5:47 UTC (Thu) by darwi (subscriber, #131202) [Link]

> QjackCtl fails to start on pipewire-jack because qjackctl uses the JACK session API

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).

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 18:17 UTC (Wed) by dbnichol (subscriber, #39622) [Link] (1 responses)

I'm not a JACK user, but https://feaneron.com/2020/12/07/switching-to-pipewire/ shows a JACK application in action on pipewire.

PipeWire: The Linux audio/video bus

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.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 18:18 UTC (Wed) by dancol (guest, #142293) [Link] (4 responses)

As an aside, isn't it time to increase default file descriptor limits? In a world where literally everything is a file descriptor --- and that's a good world! --- a process should be able to create more than a few thousand file descriptors. The current low limits feel antiquated to me.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 20:57 UTC (Wed) by josh (subscriber, #17465) [Link]

Yes, absolutely.

Someone just needs to take this upstream with a patch and clear justification.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 16:06 UTC (Thu) by floppus (guest, #137245) [Link] (2 responses)

The trouble is, that breaks everything that uses select(2).

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.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 21:39 UTC (Thu) by zuki (subscriber, #41808) [Link] (1 responses)

Yep. Systemd does that since v240:

> 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.)

PipeWire: The Linux audio/video bus

Posted Mar 6, 2021 1:01 UTC (Sat) by plugwash (subscriber, #29694) [Link]

Technically it's not select that is the problem per-se, it's the types and macros used alongside it which use a fixed-size array with no bounds checking.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 19:33 UTC (Wed) by g2boojum (subscriber, #152) [Link]

This article was very well written, explaining a lot of arcane stuff quite clearly. Thanks!

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 20:28 UTC (Wed) by jafd (subscriber, #129642) [Link] (1 responses)

There’s one thing that I cannot find an answer for, or the answer is evasive: right now I have a few things with speakers attached that speak AirPlay. Most of my family has at least one Mac, or iPhone, or an iPad, so those just work. My setup works because PulseAudio works with AirPlay too. After many years it’s in the state where it just works without me thinking about it too much. A Linux desktop nirvana.

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?

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 22:50 UTC (Wed) by flussence (guest, #85566) [Link]

PulseAudio handles all audio (AirPlay, Bluetooth, other network layers, even ALSA) via internal plugins so those would have to be ported to PW's plugin API. Which sounds like a fairly tractable task for someone with the hardware and the motivation, as it's at least a well-defined and thought-out API from what I can see.

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.

KLANG

Posted Mar 3, 2021 23:16 UTC (Wed) by vinipsmaker (guest, #126735) [Link] (2 responses)

I'm actually curious to what happened to KLANG: https://www.phoronix.com/scan.php?page=news_item&px=M...

Does anyone know of its author?

KLANG

Posted Mar 4, 2021 13:55 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (1 responses)

This article was such a pleasure to read. Informative and very well written.
Thank you!

KLANG

Posted Mar 15, 2021 6:41 UTC (Mon) by flussence (guest, #85566) [Link]

I clicked that link bracing for the worst based on the domain name, but it turned out to be from 2012 and, as you say, pretty well written. What 8 years of toxic SEO greed and no competition (RIP Kerneltrap) does to a website…

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 16:12 UTC (Thu) by vstarwalt (subscriber, #98529) [Link]

Thanks for the article especially all of the links to original sources.

PipeWire: The Linux audio/video bus

Posted Mar 10, 2021 6:25 UTC (Wed) by ghane (guest, #1805) [Link] (3 responses)

Hi,

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.

--
Sanjeev

PipeWire: The Linux audio/video bus

Posted Mar 14, 2021 13:24 UTC (Sun) by Hi-Angel (guest, #110915) [Link]

I imagine you will not have a pulseaudio process running, i.e. executing

 λ ps aux | grep pulseaudio
constan+     610  1.4  0.1 3120980 14064 ?       Ssl  мар10  80:22 /usr/bin/pulseaudio --daemonize=no --log-target=journal
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:

 λ 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

Posted Mar 17, 2021 17:08 UTC (Wed) by darwi (subscriber, #131202) [Link] (1 responses)

> How can I check if I am using it?

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.

PipeWire: The Linux audio/video bus

Posted Mar 18, 2021 12:13 UTC (Thu) by ghane (guest, #1805) [Link]

Thank you, Hi-Angel, darwi.

I can confirm that both pulseaudio and pipewire are running, as systemd user services.

Thanks


Copyright © 2021, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds