Bouzas: PipeWire, the media service transforming the Linux multimedia landscape [LWN.net]

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 8:58 UTC (Fri) by smcv (subscriber, #53363) [Link] (19 responses)

Adding features can require breaking protocol compatibility. In this case it almost certainly does, because Pulseaudio doesn't act as a security boundary between mutually distrusting apps, so Pulseaudio apps can safely assume they're fully privileged.

If Pulseaudio broke compatibility, old apps would stop working: it seems better to give the new thing a new name or major version number, and have them work in parallel (presumably one can be made to output via the other) until the last Pulseaudio app goes away, at which point you no longer need Pulseaudio.

In packages that document that they break compatibility with each major version (like GTK, Qt, and taking an example from outside Unix, Direct3D) maybe the incompatible version would have been called "Pulseaudio 2", but Pulseaudio doesn't use major versions like that: Pulseaudio 13 is compatible with Pulseaudio 1.

See also the renames between the X11 and Wayland protocols, the OpenGL and Vulkan APIs, and the Win32 and WinRT APIs. (And contrast with Direct3D, where Direct3D 12 has little in common with older versions.)

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 9:12 UTC (Fri) by mads (subscriber, #55377) [Link] (18 responses)

"until the last Pulseaudio app goes away, at which point you no longer need Pulseaudio." I don't see this happen. And saying "can require" sounds like hand-waving.

I get the feeling that the whole reason for making a new sound server is because people don't like PulseAudio for personal reasons.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 9:46 UTC (Fri) by intelfx (subscriber, #130118) [Link] (3 responses)

> I get the feeling that the whole reason for making a new sound server is because people don't like PulseAudio for personal reasons.

Haters gonna hate.

Those who disliked PA (and still do so when there are little to no rational reasons left for such dislike) can be well expected to contempt PipeWire even more.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 11:30 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (2 responses)

> Haters gonna hate.

The fact that something works for you does not imply that it works for everyone else in the world.

For several years on my computers, whenever the sound stopped working it meant that some package had pulled in pulseaudio.

Of course I'm sure I could have put in the time to debug the issue and fix it. On the other hand, why bother if removing it was all it took to fix the issue?

Also remember that the default configuration of pulseaudio does a thing about relative volumes of streams, which means you'll end up blasting full volumes sounds and possibly getting hearing damage. Distributions are expected to workaround this.

Anyway, I still don't use it because despite now it works ok out of the box, it still solves an issue I've never had. And without it I've always had multiple processes producing sounds.

So please don't be a fanboy and do not discount other people's legitimate issues just because you don't have them. It's not very inclusive.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 12:04 UTC (Fri) by intelfx (subscriber, #130118) [Link] (1 responses)

> The fact that something works for you does not imply that it works for everyone else in the world.

I'm not joining you on this flame war.

What has been said is simple: if someone dislikes PulseAudio for personal reasons (i. e., the definition of "hater"), it's more than likely that they will dislike PipeWire even more.

Therefore, it's unlikely that this specific consideration was the driving force behind PipeWire.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 18:43 UTC (Fri) by joib (subscriber, #8541) [Link]

Well, people that hate pulseaudio because Lennart will have to come up with a new excuse.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 10:07 UTC (Fri) by Wol (subscriber, #4433) [Link] (12 responses)

> I get the feeling that the whole reason for making a new sound server is because people don't like PulseAudio for personal reasons.

Well, the reason PulseAudio was written was because Alsa was fundamentally flawed, and it was easier to start from scratch. PipeWire has been written because PulseAudio is fundamentally flawed, and it's easier to start from scratch. Fundamentally, that is, as in the design itself is wrong.

PulseAudio is a sound *playback* system. If you have problems, you increase the buffer and delay the output - bit like "live" tv is delayed a couple of seconds to allow the staff to take action if something happens that shouldn't. That's why Jack was written - because the option of delaying output is simply unacceptable in a feedback situation (ie, the lead is singing con belto into a mike on stage).

So just as PulseAudio sought to provide a single unified response to the problem of sound in early linux distros (where each application thought it had total control into the sound card), now PipeWire is fixing PulseAudio's delusion that it has total control of sound output.

Cheers,
Wol

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 11:42 UTC (Fri) by mads (subscriber, #55377) [Link] (11 responses)

Why couldn't you stitch on security functionality in PulseAudio - implement it as a newer protocol, but let the daemon be backwards compatible? Why insist on breaking as much userspace as possible, and throw all those years of getting PulseAudio working with god knows what weird hardware setups are out there out with the bathwater? Bluetooth, multi speaker setups, virtual sinks, resampling, DTS, network sinks - PulseAudio does _a lot_ of difficult stuff that it took years to implement.

From the outside this all looks like some cadt thing.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 19:13 UTC (Fri) by ocrete (subscriber, #107180) [Link] (10 responses)

PipeWire actually provides a replacement libpulse.so, so applications shouldn't see the difference.

Wim actually started by trying to add security enforcement to PulseAudio, and it quickly turned into a disaster. And that is before starting to talk about unfixable design issues that make the latency quite high. And then having latency means you need things like rollback: being able to undo any effect you apply and re-apply a new effect, so that changing the volume is instant. All of those things make the PulseAudio code quite complex in ways that PipeWire is a much more simple and elegant solution.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 7, 2020 15:53 UTC (Sat) by kleptog (subscriber, #1183) [Link] (5 responses)

So Pulse did one thing right, they defined an API that was sensible enough that the implementation could be swapped out and replaced with a better one.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 8, 2020 22:33 UTC (Sun) by Wol (subscriber, #4433) [Link] (4 responses)

Not really. As far as I can make out, part of PulseAudio was was a soundcard emulation you could stick aRts on top, so several applications could be fooled that they had sole control of the sound card.

So now you have an interface where you fool PulseAudio into thinking it has control of the soundcard ...

This is the way computing *should* advance - the new layer fools the old layer into thinking nothing's changed ... I always think of IBM mainframes, where an IBM 360 program runs on a virtual 360, which used to run on a 370 and now runs on a virtual 370 which runs on ... well I don't know the progression of mainframes, but old 360 applications sit on top of three or four emulators to run on the latest hardware.

Cheers,
Wol

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 17, 2020 21:49 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

That's almost entirely wrong. One thing PA did right -- and PipeWire is following suit -- was to mimic the userspace APIs of almost all previously-existing sound server systems, so it could support almost all existing userspace programs. This was very difficult for OSS and ALSA -- it had to use an LD_PRELOAD wrapper you had to turn on explicitly for programs that needed it -- but for everything else it was more or less trivial. At no point in this does PA do anything one could reasonably describe as "soundcard emulation". Equally, PipeWire's PA emulation does not work by kicking up a copy of PulseAudio and giving it a virtual sound card: it merely provides a shared library that makes PipeWire appear to be PulseAudio to PA consumers using that shared library (basically all of them). The thing on the other end of the shared library is PipeWire, not PA-talking-to-an-emulated-sound-card.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 18, 2020 11:06 UTC (Wed) by smurf (subscriber, #17840) [Link] (1 responses)

Well, it didn't emulate the soundcard hardware, that's the kernel's domain in any case, but it did (and still does, in case anybody needs it, which is rather unlikely these days) emulate the OSS driver.

ALSA is/was way easier, pulseaudio hooks itself into it reasonably seamlessly, though the extra layer is painfully visible at times.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 19, 2020 22:00 UTC (Thu) by nix (subscriber, #2304) [Link]

Yeah, it had to emulate whatever API was available, and for OSS that meant it had to intercept mmap and stuff like that. It's still not actually emulating a *sound card* though.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 18, 2020 14:55 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> At no point in this does PA do anything one could reasonably describe as "soundcard emulation".

For ALSA, PulseAudio provides an ALSA plugin which connects to PA. That is essentially PA emulating a sound card, if one considers other ALSA plugins like dmix or plughw which appear the same as sound cards to applications to be "soundcard emulation". Only OSS required the LD_PRELOAD, since OSS applications accessed the device nodes directly. With CUSE and osspd to provide literal "soundcard emulation" for OSS apps one doesn't even need that.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 7, 2020 21:07 UTC (Sat) by luto (guest, #39314) [Link] (3 responses)

How does PipeWire handle latency? Suppose I have an audio device with a big enough buffer for 5s of audio. If an audio player is running on an otherwise idle system, ISTM the most efficient strategy is to queue up several seconds of audio every few seconds. If the user hits pause or changes the track, that buffer needs to be zapped immediately.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 8, 2020 17:16 UTC (Sun) by Wol (subscriber, #4433) [Link]

Dunno, but you're missing the Jack compatibility.

As far as Jack is concerned you can NOT buffer the audio - it needs HARD realtime with a latency measured in fractions of a millisecond. (Miss that target, and the result will - literally - be painful for your listeners.)

If you've got sub-millisecond latency, sounds like your requirements would be fairly easy to meet.

Cheers,
Wol

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 14, 2020 13:03 UTC (Sat) by wtay (guest, #55923) [Link] (1 responses)

>How does PipeWire handle latency?

It keeps buffers as small as the lowest requested latency by all clients. The largest buffer it can fill is 8192 samples (171ms). Buffers are usually 1024 samples or 21ms.

It will wake up more often and never needs to zap large buffers. This makes things much less complex so that you can make those frequent wake-ups so much more efficient.

There is some performance data here:
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/...

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 19, 2020 3:19 UTC (Thu) by flussence (guest, #85566) [Link]

I'm surprised PA seems to not even bother with its “intentional bufferbloat” mode of operation until the very last test; that's supposed to be one of its main features.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 19:53 UTC (Fri) by flussence (guest, #85566) [Link]

At one time, people acted like esound/aRts would never go away too. They were unavoidable, as was the cursing people shot at them. PulseAudio isn't going to be an immutable foundation either.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 9:48 UTC (Fri) by smurf (subscriber, #17840) [Link]

PulseAudio does single-pipe audio. Teaching it to handle the complete multimedia landscape, including screen recording and whatnot, *and* adding a security model would be a lot of work rewriting code and ensuring that every old code path and every existing module fits into the new larger scheme.

Better to start with a design that takes all of this into account from the beginning and worry about PA compatibility later, it's not that difficult (in contrast to JACK, pulseaudio doesn't even require hard realtime – you can just increase the deadline and ask your source to send the audio earlier if things are tight) and frankly the least of your worries when writing a new multimedia subsystem.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 11:13 UTC (Fri) by kazer (subscriber, #134462) [Link]

One of the things involves lifting session and policies out of the audio "daemon" so that it won't decide things for you. I imagine very low latency (for professional audio) would be hard as an afterthought as well..

But it looks like PW has stable API that is backwards-compatible with PA already.

Bouzas: PipeWire, the media service transforming the Linux multimedia landscape

Posted Mar 6, 2020 13:10 UTC (Fri) by darwi (subscriber, #131202) [Link]

> Why can't these features be added to PulseAudio?

Unfortunately the security issues are unfixable due to core design decisions made by PA in its very early days. I've summarized these issues some long time ago here:

https://www.freedesktop.org/wiki/Software/PulseAudio/Docu...
https://lists.freedesktop.org/archives/pulseaudio-discuss...

This is not to blame PA by the way. As said in the article, it was created in a completely different time. Computer usage scenarios are much different today.