undefined | Better HN

0 pointsAshamedCaptain3y ago0 comments

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

0 comments

Crysstalis3y ago

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

AshamedCaptainOP3y ago

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

Crysstalis3y ago

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

1 more reply

j / k navigate · click thread line to collapse

0 pointsAshamedCaptain3y ago0 comments

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

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

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.

0 comments

Crysstalis3y ago

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

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

AshamedCaptainOP3y ago

> 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'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, you're mixing this up. Applications should indeed probably use something like gstreamer, and then gstreamer targets the PA APIs.

Crysstalis3y ago

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

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

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

1 more reply

j / k navigate · click thread line to collapse