1. PulseAudio needed a redesign, there was no fixing to be done. It was utterly impossible to support low-latency audio, the protocol was not right, the client API was wrong, the backend was not right etc.. Also, ALSA is the wrong place to add more things, it should just be a driver abstraction.
Also note that PipeWire reuses the most complicated/fundamental part from PulseAudio: the device probing and mixer management. This code took 10 years to tweak and is taken directly from PulseAudio.
As a side note, there was a lot of investigations if things could be written on top of JACK2 but that also was infeasible (mostly the IPC protocol and API needed a rework, no security with memory sharing, support for Video. The scheduling ideas were taken right from jack2, though).
2. This is true but PipeWire is not just a random new rewrite. It was written with a deep understanding of both pulseaudio and JACK (later in the developments) internals and design. Many (of the good) ideas from those projects survived in PipeWire. This is actually a perfect example when a rewrite is a good thing.
Now, what is even easier than writing PipeWire is not understanding why things are done the way they are done and then complaining about it.
> but if you keep changing things that don't need changing (ALSA -> PulseAudio -> pipewire -> whatever is already in the works to replace pipewire) instead of ACTUALLY FIXING THEM
This is possibly the dumbest thing I read in a while...
1. PipeWire was written to fix PulseAudio and is a drop in upgrade. How do you think things get fixed otherwise?
2. Why would anyone rewrite PipeWire at the moment, why would you think that?
Hi, I'm maybe one of those moronic retards you talk about. Please, please help us out! The world is eagerly awaiting your super non-garbage solutions. Please show us the way... You could be a hero!
The answer is, surpisingly maybe, no. JACK (and PipeWire) manage to add features without adding any latency to what ALSA can provide. Will it consume more CPU? yes, it does...