[Crysstalis]

>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.

[AshamedCaptain]

> 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.

I really don't see why. Do note that dmix runs in user-space like any other sound server. Certainly it never had dynamic audio stream routing, but it is something that could have been added with a plugin...

I actually wrote a simple ALSA plugin for bluetooth audio back in the day (not the current one) and the biggest problem was that (as usual for the ALSA API) plugins just cannot emulate all the functions of the ALSA API (e.g. mmap), not to mention that some closed source programs even banged the kernel directly anyway. Since these programs wouldn't work with the ALSA pulseaudio module, I'm assuming this is no longer a problem today.

I'm not advocating ALSA (it's a mess), it's just to say that again, PA did not bring much to the table at the time.

> Sorry, I thought you meant the API that allows you to queue buffers and allows applications to make use of that glitch-free feature

No, I specifically mean the use of large buffers and rewind usage compared to smaller buffers. See https://lwn.net/Articles/847412/ (just grep for rewind). Pipewire explicitly does not do this, and while it can result in increased CPU utilization due to more interrupts when lower latency is required (and the default latency is quite low), performance of Pipewire turned out to be still competitive.

> No, you're mixing this up. Applications should indeed probably use something like gstreamer, and then gstreamer targets the PA APIs.

What is it that I'm mixing up? Lennart himself said that most programs should not target the PA API. See http://0pointer.de/blog/projects/guide-to-sound-apis (2008). Literally the only category where he recommends PA API is for a mixer program; for everything else he recommends ALSA or gstreamer.

The "proof" that I mention is that most programs ended up targeting the PA API _anyway_ , despite the recommendations of the author. Which forced Pipewire to implement the PA API in order to provide a smooth transition (otherwise it would break everyone's audio _again_). Likely people used PA API because it is the lesser evil if you compare it to ALSA, and because people generally are afraid of abstraction layers (same reason libao and friends get little love, perhaps with reason).

[Crysstalis]

>Do note that dmix runs in user-space like any other sound server.

Dmix is explicitly not a sound server, it is a plugin implemented in the alsa library that does "cooperative" mixing of the sound in an shm region. Adding all those other features and turning it into a daemon is a rather roundabout way to re-implement pulseaudio.

>No, I specifically mean the use of large buffers and rewind usage compared to smaller buffers

Right, but an application can still submit a large buffer that then needs to get muxed down. Pipewire has to account for this possibly by emulating that rewind inside the daemon.

>Lennart himself said that most programs should not target the PA API

I think you have missed this emphasized part:

>For now, the PulseAudio API should be used only for applications that want to expose sound-server-specific functionality (such as mixers) or when a PCM output abstraction layer is already available in your application and it thus makes sense to add an additional backend to it for PulseAudio to keep the stack of audio layers minimal

So that would be why gstreamer targeted the PA API, anyway.

>The "proof" that I mention is that most programs ended up targeting the PA API _anyway_ , despite the recommendations of the author

That article was written in 2008, things changed since then. Wim is currently saying the same type of things about the pipewire API (because it is unstable and unwieldy) but I suspect eventually it will become stabilized, gain some convenience features and then become used by applications just like the PA API...

[AshamedCaptain]

> Dmix is explicitly not a sound server, it is a plugin implemented in the alsa library that does "cooperative" mixing of the sound in an shm region. Adding all those other features and turning it into a daemon is a rather roundabout way to re-implement pulseaudio.

I don't understand the purpose of this semantics discussion. I was just trying to say that dmix was very alive and growing, and for a time it even was going to be the replacement of the mostly-useless DE-specific sound servers, which are the reason many were abandoned. Whether you want to call it a sound server or not is irrelevant since it fulfilled the same role and had the same features as other sound servers of the era.

> Right, but an application can still submit a large buffer that then needs to get muxed down. Pipewire has to account for this possibly by emulating that rewind inside the daemon.

The point was that Pipewire didn't follow this Pulseaudio-specific design which actually was one of the primary technical improvements in Pulseaudio and at the same time the major cause of incompatibilities.

> I think you have missed this emphasized part

No, I have not missed this emphasized part. The point was that Lennart himself said that most programs should not target the PA API. Unless you are going to claim that gstreamer itself is "most programs" , my point still stands: Lennart himself said that most programs should not target the PA API.

> That article was written in 2008, things changed since then.

Actually, not much has changed since then in either ALSA or PA APIs. Everyone (including Lennart) _still_ recommends you target the ALSA API directly.

But, anyway, the point was to show that even despite the recommendation of the author of one of the APIs not to use it at the time, everyone used it anyway, further complicating the mess, and resulting in PW having to implement the PA API for a smooth transition.

If only stuff like gst had used the PA API, PW could have just shipped a gst module and called it a day. There would have been absolutely no reason to implement the PA API at all. Well, other than the gnome mixer program.

[Crysstalis]

>I don't understand the purpose of this semantics discussion

>Whether you want to call it a sound server or not is irrelevant since it fulfilled the same role and had the same features as other sound servers of the era.

This is not semantics from me, you are trying to say the phrase "sound server" doesn't mean anything, or it actually means "servers but also plugins". No, that's not true. It has specific meaning. You are limited as to what you can do in an alsa plugin. It is not the same as having a daemon running.

If you are saying from the perspective of the ALSA API, the interface is the same as dmix, that is true. Those sound servers have just provided their own pcm. If you want to use this to say "I don't care as an application developer if it's a plugin or a sound server" then that should also show you that the approach of dmix is not all that great or important.

>The point was that Pipewire didn't follow this Pulseaudio-specific design

And I will say again that what Wim actually did was intentionally choose a design that could easily be used to implement a Pulseaudio-specific design on top of it. That is why pipewire-pulse is able to work. You can ask him about this yourself, I would rather not go back and forth with this hearsay.

>Unless you are going to claim that gstreamer itself is "most programs"

You have missed the point of that part though. Transitively it may very well be "most programs" if you use a lot of media apps, because those apps will use gstreamer which then uses pulseaudio underneath. Anyway I think it is pointless for you and I to keep harping on this one person's opinion, because that's all it is. An opinion on a blog. This is really not worth getting worked up over.

>Everyone (including Lennart) _still_ recommends you target the ALSA API directly.

He can recommend that all he wants. As you have found out, in open source that doesn't stop people from using the API. They will use whatever they want, for better or worse, irrespective of whether it will complicate the mess or not. Actually I would say all of open source is just a big complicated mess that will never reduce as long as it keeps growing.

>If only stuff like gst had used the PA API, PW could have just shipped a gst module

They did do that, this is not enough to call it a day though because it would not ensure binary compatibility with old gstreamer builds that don't have the new module. Also that is only one library, it doesn't count all the other libraries that fall underneath this category that may not support modules. The suggestions you are making are either not realistic or are hypotheticals based on hindsight. Of course, had anyone known all these issues years ago, they might have made OSS the perfect API at exactly the right time and then there would be no fragmentation. But the ship has sailed on that.