LWN: Comments on "Bouzas: PipeWire, the media service transforming the Linux multimedia landscape"

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

nix — Thu, 19 Mar 2020 22:00:59 +0000

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

smurf — Thu, 19 Mar 2020 12:33:39 +0000

Not much better, last time I tested that. Wifi is not a realtime transport … I have taught my Wifi receiver (just one thankfully) to get its stream via icecast, that tends to work OK.

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

mgedmin — Thu, 19 Mar 2020 12:21:47 +0000

When I last tried to transfer sound over the network with PulseAudio over wifi, I got regular skips every couple of minutes or so seconds. Annoying, unusable. (Today I suspect that what I experienced was my wifi driver doing periodic background scans so the network manager menu could show me all the avalable wifi networks. I think it can be turned off, but how many users will be able to figure it out?)

What worked surprisingly well was running mplayer over ssh so the sound played locally, and the video was displayed over X11 over wifi.

This was maybe in 2005, so I would love to hear how well things work nowadays.

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

flussence — Thu, 19 Mar 2020 03:19:09 +0000

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

nybble41 — Wed, 18 Mar 2020 14:55:35 +0000

> 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

smurf — Wed, 18 Mar 2020 11:06:01 +0000

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

nix — Tue, 17 Mar 2020 21:49:16 +0000

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

smurf — Sat, 14 Mar 2020 16:58:30 +0000

The flip side is that under PipeWire pavucontrol needs a whole lot more network bandwidth. Not an issue locally but a potential problem when we're talking about a larger network of servers.

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

wtay — Sat, 14 Mar 2020 13:15:41 +0000

>pavucontrol is not compatible with PipeWire so it's not like PipeWire can improve over that anyway.

You can run pavucontrol under pipewire just fine and I often do to check signals and change volumes etc.

Pipewire runs the peaks resamplers in the pavucontrol process. The effect is that the load is shifted from the server to the client. I don't have numbers to compare but I remember pavucontrol uses approximately the same CPU while the Daemon much much less in the case of pipewire.

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

wtay — Sat, 14 Mar 2020 13:03:29 +0000

>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

wtay — Sat, 14 Mar 2020 12:51:23 +0000

>Can Pipewire transfer its payload over network? Like netjack*[1] or pulseaudio[2]?

It does not have anything nicely integrated yet but you can run zita-n2j for example

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

wtay — Sat, 14 Mar 2020 06:53:32 +0000

> Please, let's stop the hand-waving and anecdotes and concentrate on what PipeWire actually >TECHNICALLY does (or even theoretically could do) that's so much better.
>
>My issue is that TFA and other official PipeWire sources make sweeping claims suggesting that >PulseAudio is high-latency, resource-intensive etc and then do nothing to back those claims up, >nor explain how they improve over it. And this comment thread is just another example of that.

I have posted some Performance measurements between PipeWire, PulseAudio and JACK2 on the Wiki now: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/...

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

intgr — Fri, 13 Mar 2020 21:15:41 +0000

> doesn't list pavucontrol as deprecated

Sorry you are right, it's not deprecated. I may be confusing it with "paman".

But it's my understanding that pavucontrol was not intended to be the primary UI, in favor of tools integrated into the desktop system, such as "gnome-control-center sound". This sentiment is already present in a 2007 post by Poettering about integrating PulseAudio with Gnome. [1] So I don't consider CPU usage of a specialist UI to reflect badly on PulseAudio itself.

[1] https://mail.gnome.org/archives/desktop-devel-list/2007-O...

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

motiejus — Fri, 13 Mar 2020 16:01:44 +0000

Can Pipewire transfer its payload over network? Like netjack*[1] or pulseaudio[2]?

I would love to send digital audio from desktop to my receiver without an hdmi cable with reasonable latency (may rule out pulseaudio) and with least moving parts (rules out pulseaudio+jack).

I tried looking around, to no avail.

[1]: https://jackaudio.org/faq/netjack.html
[2]: https://wiki.archlinux.org/index.php/PulseAudio/Examples#...

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

jschrod — Fri, 13 Mar 2020 11:50:54 +0000

> The pavucontrol UI is deprecated

Could you please elaborate what should be used instead?

https://www.freedesktop.org/wiki/Software/PulseAudio/About/ doesn't list pavucontrol as deprecated; i.e., it's not in the section "obsolete or out-of-date UI tools".

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

intgr — Tue, 10 Mar 2020 10:42:10 +0000

> Open pavucontrol and the thing goes from 5% to 50% CPU
That may be true but it's a red herring; I'm interested in behavior under normal circumstances. The pavucontrol UI is deprecated and normal users don't keep it open for long periods of time. pavucontrol is not compatible with PipeWire so it's not like PipeWire can improve over that anyway.

> but it doesn't have hard bounds on its latency either. You add a sink that delays for half a second? fine, that's your new channel latency
In normal circumstances you output to a single sink at a time. If your sink has high latency, well, there's nothing that PipeWire can do to improve that either, right?

Please, let's stop the hand-waving and anecdotes and concentrate on what PipeWire actually TECHNICALLY does (or even theoretically could do) that's so much better.

My issue is that TFA and other official PipeWire sources make sweeping claims suggesting that PulseAudio is high-latency, resource-intensive etc and then do nothing to back those claims up, nor explain how they improve over it. And this comment thread is just another example of that.

For comparison, PulseAudio has technical explanation about how they implement a *low-latency* and low-wakeups (i.e. not resource intensive) sound server: http://0pointer.de/blog/projects/pulse-glitch-free.html and it seems to me it does everything it can within the constraints of the hardware.

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

abo — Tue, 10 Mar 2020 09:57:36 +0000

PulseAudio was created back when single core Pentium 4:s was still a thing, but I remember having to temporarily kill it and configure VLC to go directly to ALSA to get smooth video playback.

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

abo — Tue, 10 Mar 2020 09:55:45 +0000

If the audio system is also the video system it can delay the video to match.

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

smurf — Tue, 10 Mar 2020 06:50:07 +0000

There's a number of things you can do. Like blocking the connection of a new sink if it introduces a delay of more than .1 second or whatever, or keeping it out of the loop.

For instance, a phone call on Bluetooth with that kind of delay is annoying but survivable, while he same thing on speaker is not. Also, a phone call shouldn't suddenly goes from .05 to .5 seconds latency because Pop's hearing aid also wants to listen in.

Decisions like these (do you *want* Pop to listen? should his microphone be cross-connected? or should the call switch to him entirely?) should be under the purvey of a policy manager, not any single application. PA doesn't have that.

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

foom — Tue, 10 Mar 2020 05:12:49 +0000

But if I _do_ have a sink that delays by half a second (eg Bluetooth sometimes), what's the audio system gonna do better than to report it?

Sure, that's an extremely obnoxious delay, but isn't it good if it can deal with that reality as best as possible, instead of falling over?

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

andrel — Mon, 09 Mar 2020 22:43:54 +0000

Didn't know about x2go, thanks for the suggestion!

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

smurf — Mon, 09 Mar 2020 21:32:45 +0000

Yeah, I know. But that's not a good-enough excuse for 50% load. That 5% is caused by one or two application sources going to one hardware sink. Everything else is dormant. Thus PA's pavucontrol would only have to enable my three hardware sources, preferably with suitably lowered bitrate. Thus, 15% at most. Everything above that is bad design (and would kill audio on a system that does actual multi-channel processing).

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

mathstuf — Mon, 09 Mar 2020 21:03:46 +0000

Could it change the strategy based on whether the networking support is loaded or not?

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

flussence — Mon, 09 Mar 2020 19:37:44 +0000

pavucontrol creates ~30Hz taps for all sources/sinks in order to show the fancy VU meters. It could capture the raw streams and pay the CPU cost in its own process, but then someone else would probably complain that PA stops working over their wifi when it's open.

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

smurf — Mon, 09 Mar 2020 16:46:26 +0000

Well, it is. Open pavucontrol and the thing goes from 5% to 50% CPU if your setup is sufficiently interesting. I reported that years ago. Yes it's reproducible.

PA is not high-latency per se, but it doesn't have hard bounds on its latency either. You add a sink that delays for half a second? fine, that's your new channel latency, and your video player needs to notice the change and deal with it. That's fine if your source is in fact a video player, not so if it's a live phone call. Add a multi-microphone setup with a DSP that's supposed to isolate the driver's voice from all the other noises in and around the car (not to mention the other side of the phone call) and you're in trouble.

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

intgr — Mon, 09 Mar 2020 15:29:25 +0000

How come all these people are suddenly coming out of the woodwork claiming that PulseAudio is inefficient, resource-intensive and high-latency?

But back in the day I read several blog posts about PulseAudio where it appeared to go out of its way to reduce context switches and offer best latency possible with minimal CPU wakeups, with some clever buffer trickery (compared to something like JACK that does it by brute force, by reducing audio buffers to a minimum and causing a high number of CPU wakeups).

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

alexl — Mon, 09 Mar 2020 15:29:11 +0000

Not by design, you can't just point it to some .so and load that. However, I wouldn't be shocked if there is an exploit somewhere in some module you can trigger.

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

Wol — Sun, 08 Mar 2020 22:33:43 +0000

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

Wol — Sun, 08 Mar 2020 17:16:41 +0000

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

luto — Sat, 07 Mar 2020 21:07:50 +0000

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

kleptog — Sat, 07 Mar 2020 15:53:02 +0000

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

seneca6 — Sat, 07 Mar 2020 12:15:35 +0000

Did you try x2go?

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

comex — Sat, 07 Mar 2020 09:26:51 +0000

It’s relatively new (added in the 2018 release), but macOS does have a per-app permission prompt for microphone access. (And another one for camera access.)

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

flussence — Fri, 06 Mar 2020 19:53:27 +0000

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

ocrete — Fri, 06 Mar 2020 19:18:23 +0000

The goal is not to reproduce Windows/macOS, both of which has designs that date from the same era as X11 and PulseAudio. In that era, the idea was that all applications were trusted and could have almost full access to the computer. PipeWire is trying to bring the Linux OS to the era of Android and iOS, where you can run less trusted applications, because they only have access to the minimal persmissions.

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

ocrete — Fri, 06 Mar 2020 19:16:23 +0000

The mention to Flatpak is because PipeWire's security enforcement makes it possible to allow only limited audio access to Flatpak'ed applications. For example, you can allow an application to playback, but not to capture from a microphone, etc. While the PulseAudio model means that if you give access to an application, it has full access to the audio system.

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

ocrete — Fri, 06 Mar 2020 19:13:53 +0000

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

joib — Fri, 06 Mar 2020 18:43:18 +0000

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

gfernandes — Fri, 06 Mar 2020 18:29:25 +0000

Thanks for the explanation! :-)

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

gfernandes — Fri, 06 Mar 2020 18:28:33 +0000

Thanks! That's a relief.

I guess I misread this from the linked article:
"A huge effort is currently underway to bring the Linux desktop into the future with the help of containerization technologies such as Flatpak."