>but ALSA's userspace/plugin one (dmix) was definitely not abandoned and not stagnating. It was actually growing, and the advice then was to target ALSA API directly, not a specific sound server. The same advice is still valid today.
Dmix was always a poor solution for desktop sound. It can do mixing but that's not the whole story. To have any kind of concept of audio streams and routing, it has to be done in a daemon. It can't be added with just alsa plugins. The correct way to use alsa currently is actually to use the pulse/pipewire pcm, so you can use the simplest parts of the ALSA API without any of the drawbacks.
>At least from my point of view, the problem with Linux sound has been one of APIs.
Well, that's just the problem isn't it? To make the "one API to rule them all" you have to make an API that encompasses all of them, and it becomes as complicated as all of them combined.
>That's not the full story.
I thank you for sparing the details, but my point was, I am sure you can summarize it without accusing someone of malice.
>Anyway, "being slow for accepting patches" is another word for "unmaintained" which you literally complained above and argued it is a point for justifying a replacement.
Yes, I have no complaints about pipewire.
>What I was referring to is the glitch-free feature from Pulseaudio which is what actually broke most people's audio.
Sorry, I thought you meant the API that allows you to queue buffers and allows applications to make use of that glitch-free feature. That part is implemented in pipewire-pulse. Because why wouldn't it? Pipewire is designed that way because it's easy to add buffering on top of the "traditional" approach than it is to do the reverse. That decision was made actually because it allowed Wim to implement both the pipewire and PA APIs effectively.
>Pipewire implementing the PA protocol is just more proof of the disaster that are the Linux audio APIs. Even Lennart said most people should not target the PA API.
No, you're mixing this up. Applications should indeed probably use something like gstreamer, and then gstreamer targets the PA APIs. Gstreamer also does support this type of buffering and I would imagine this is one of the reasons why PA also supports it.
