[AnIdiotOnTheNet]

People keep talking about how terrible Pulse is for them, but my decades of experience using Linux desktop recalls that for whatever faults Pulse might have it was a huge improvement over the shitshow that was Linux audio before it.

[AshamedCaptain]

I adopted Pulseaudio back when it was still called Polypaudio, so I am aware of the problems of Linux audio before it, but PA was just yet another sound server in a world that was already full of them and didn't really bring anything to the table. Linux audio world is exactly as much of a shitshow today as it was before PA. Lennart didn't even envision people writing the PA API directly, but rather going through gstreamer (then a fancy new thing) or the like.

Pulseaudio got popular and then became "irreplaceable" because it started playing a role that would have been played by HAL back in those days; i.e. setting up audio policy (routing, etc) whenever the kernel would fail at it. I was very critic of Pulseaudio, a sound server, incorporating this role, and argued that this complexity would make this project impossible to replace with a newer sound server when it inevitably came. I was proven wrong, albeit in my defense the replacement Pipewire did require a shitton of effort, and PA was becoming toxic in the meanwhile (see the Bluetooth codecs drama).

Pulseaudio's "big" technicaly improvement ("glitch-free" audio, aka interrupt-less, long buffers), and without a doubt its major cause of annoyances to users (since it exercised a lot of rarely used APIs), has not been adopted by Pipewire (which goes back to "low latency" + lots of interrupts) or any other sound server for the matter. (And Pipewire still manages to have better performance...)

[Crysstalis]

>but PA was just yet another sound server in a world that was already full of them and didn't really bring anything to the table

I seem to remember that the main thing it did was bring "being maintained" to the table, because esound was unmaintained and stagnating. I still find this to be really ridiculous that people complain about supposed "hostile takeovers" in open source when, for a lot of categories of project, there are still somewhere between zero and one alternatives for any given thing. All you have to do to become the top dog is make something that does the bare minimum and doesn't crash, and has like, one person to triage bugs.

>PA was becoming toxic in the meanwhile (see the Bluetooth codecs drama).

I also still find this to be really ridiculous when people call maintainers "toxic" for being slow or for rejecting patches. Every open source project does that.

>has not been adopted by Pipewire

Actually it has, Pipewire implements the pulse protocol for backwards compatibility. The pipewire developers are also still encouraging developers to use it because it is a lot nicer to use than the pipewire API.

[AshamedCaptain]

> I seem to remember that the main thing it did was bring "being maintained" to the table, because esound was unmaintained and stagnating.

Well, that's true in so far as the useless DE-specific sound servers, 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.

At least from my point of view, the problem with Linux sound has been one of APIs. OSS API is simple but limiting. ALSA API is a complex mess that no one bothers to implement fully and/or correctly. The various sound server APIs are sound server specific and range from the simple but limiting again (e.g. esd), complicated and still limiting (e.g. arts, PA) or just too complicated (e.g. jack). Using gstreamer as just a sound output API is not taken seriously.

The only reasonable option is to use a libao-like wrapper.

> I also still find this to be really ridiculous when people call maintainers "toxic" for being slow or for rejecting patches. Every open source project does that.

That's not the full story. 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.

> Actually it has

No, it hasn't. What I was referring to is the glitch-free feature from Pulseaudio which is what actually broke most people's audio. This entire approach with longer buffers, few/no hardware interrupts and copious usage of ALSA's rewind feature (a deadly combination which broke most ALSA drivers). Compare with Pipewire which goes back to a more "traditional" small buffers and low latency approach.

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.

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