OSSv3 was a kernel API supported by a bunch of Unixoids including Linux. It had some limitations, and while OSSv4 addressed them OSSv4 was proprietary, and so

OSSv3 was a kernel API supported by a bunch of Unixoids including Linux. It had some limitations, and while OSSv4 addressed them OSSv4 was proprietary, and so on Linux it was replaced by a new thing: ALSA. (OSSv4 was eventually released under the GPL, 5 years later, but by then the ship had sailed.) ALSA is low-level enough that it's necessary for a layer on top of it. Well, maybe… enough people think so. So that's where Pulse and Jack come in. Pulse and Jack do the "same" thing, but target different use-cases and so have different design constraints; Pulse serving consumer audio and Jack serving pro audio. The creator of Pulse wrote a good article about this, about why Pulse and Jack aren't competing with eachother[1]. So for a long time that was the choice: Pulse or Jack (and whichever you choose, it's using ALSA on the backend). The same article goes on to write "One question asks itself though: can we marry the two approaches? Yes, we probably can, MacOS has a unified approach for both uses. … let's not forget that we lack the manpower to even create such an audio chimera." Well, that's what PipeWire is. It's a system that fills both use-cases. Additionally, it implements both the PulseAudio and Jack APIs, and so users don't need to care which API a given application was implemented with, and can just use PipeWire as a drop-in replacement for both. [1]: http://0pointer.de/blog/projects/when-pa-and-when-not.html http://0pointer.de/blog/projects/when-pa-and-when-not.html More reading: http://0pointer.de/blog/projects/guide-to-sound-apis.html http://0pointer.de/blog/projects/guide-to-sound-apis.html