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