[throwaway82652]

>Can someone explain to me what pipewire's goal is? to be a better pulseaudio?

Yes, and also the goal is to support video in addition to audio.

>if so, in what way is it trying to be better?

Well in addition to supporting video, it also supports jack clients without needing to run a separate server. There are a few other things like better security policies, but those are the major ones.

>also, how's the codebase quality? from what i heard, pulse's codebase is a mess, so if it can improve in that sense, i guess that's a win (?)

Pulseaudio's code is fine and pipewire is about the same, it's a relatively small core daemon with most of the major functionality split out into a large collection of loadable modules.

>why does it do video?

A few reasons, but the major one is because video on Linux has the same problem as audio: the low-level device API (V4L) can only be used by one program at a time. This leads to failures if you try to do something like access your webcam in two applications at the same time. Most applications should basically not be using ALSA or V4L directly to access devices for this reason. A sound server like pulseaudio is the typical way to mux/demux the audio devices to allow multiple applications to access it at once, and now pipewire extends that to video.

>is trying to do media capture like OBS or be a compositor like wayland?

Neither, it's used to route video sources between programs. Media players and cameras and Wayland compositors that want to do screencasting can send their video into pipewire; casting programs like OBS or any ffmpeg-based tools can receive any of these video streams from pipewire and do whatever they want with them, or could also output to pipewire so another program can consume their output. If applications support it then the idea is you'll be able to easily connect together any two applications that produce/consume video and it'll all just work.

[snvzz]

>Pulseaudio's code is fine

No, it isn't. Pulseaudio is based on a push model, which is completely broken.

Pipewire uses a pull model, like BeOS/Haiku and jack. It is suitable for pro audio, which pulseaudio could never hope to support.

[throwaway82652]

>No, it isn't. Pulseaudio is based on a push model, which is completely broken.

These two statements are both very wrong. The push model is absolutely not broken, it's actually better for media players, networked sound and other non-pro-audio applications because it uses less power and can do more efficient buffering strategies. You're right that it's not good for pro-audio and other latency-sensitive applications, but pulseaudio was not designed to do that on purpose because jack already filled that niche. The pull model has to wake up every application every quantum on a strict deadline to do processing. In some situations pulseaudio should still be able to provide the smallest power usage compared to pipewire, even just continuing to use the pulseaudio API to do buffering on top of pipewire should be a benefit for applications that want it.

Even if it was broken (it's not), that would be an aspect of the design, not the code itself. The code itself is structured in mostly the same way as pipewire.