Making Sense of the Audio Stack on Unix

Re:Making Sense of the Audio Stack on Unix by cycloptic on Sunday February 07, 2021 @06:00PM (#26059037)

I can't say I've had the same experience, I've been using jackd successfully for around 15 years now. The modern Linux answer to audio fragmentation is Pipewire, and that should actually have less fragmentation than on Windows because it preserves ABI compatibility. (It's not entirely stable yet though)

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by da_big_ghey on Sunday February 07, 2021 @06:38PM (#26059274)

Pipewire API is stable as of pretty recently: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...

It already works better than pulse for bluetooth stuff, by a long shot. wtay is a good guy who is committed to the project, as opposed to the pulse maintainers who are jerks.

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by pitterpatter on Monday February 08, 2021 @02:44AM (#26061810)

>as opposed to the pulse maintainers who are jerks.

That doesn't seem fair to just throw out without proof. In all the interactions I've seen them in, they've come across alright for the most part.

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by da_big_ghey on Monday February 08, 2021 @07:19AM (#26063512)

Sure, here's a good example: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...

Maintainers unresponsive, talking about making changes but not following up. They strung the guy along for quite a while on this new codec selection mechanism problem. They claim to be in a v14.0 freeze for two months. He updated his code to work on new v14.0 to more unresponsiveness from maintainers about merging. And it goes on from there.

If you've had to use pulseaudio-modules-bt or pali's patched version rather than official pulse, this is why. By comparison, pipewire managed to get it working with little effort because its lead developer is a nice guy and responsive.

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by pitterpatter on Monday February 08, 2021 @02:02PM (#26068603)

I understand both side's perspective here. I've been a contributor just waiting around for my changes to get merged. But I've also been on the other side maintaining a project which is no small feat. There's a lot that goes on that isn't obvious.

Overall a really unfortunate turn of events there. On a personal note I've been watching that space for awhile and was looking forward to Pali's great work on bluetooth.

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by nikanj on Monday February 08, 2021 @02:33AM (#26061750)

Alas, stable API doesn't mean the software itself is actually stable and bug-free

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by da_big_ghey on Monday February 08, 2021 @07:20AM (#26063520)

Definitely fair; I still encounter bugs. But that was true of pulseaudio as well, and it is true of pipewire to a significantly lesser extent, especially around bluetooth profile switching, interoperability with jackd, etc.

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by ahartmetz on Monday February 08, 2021 @08:49AM (#26064359)

The Pipewire author is the guy who basically made GStreamer good by overhauling its core logic back in the day - he really knows what he is doing. I fully expect that Pipewire will make audio on Linux really good (latency of Jack, consumer audio feature set of Pulseaudio, reliability of GStreamer) when it's done.

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by hctaw on Sunday February 07, 2021 @06:22PM (#26059175)

More fragmentation is not the solution to current fragmentation...

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by atoav on Monday February 08, 2021 @02:50AM (#26061846)

While I usually would say the same, as I understood pipewire they are trying to create a unifying abstraction layer with a stable API that handles the underlying cruft.

While I would have wished for a good clean solution from the start, the state of the current Linux Audio stack doesn't IMO really allow for such a solution without breaking every program ever.

If Linux Audio needs one thing it would be something that handles the weird relationships between ALSA/Pulseaudio/Jack in a clear and automatic fashion. Because as for now I have seen Linux Sysadmins with 30 years of experience tear their hair out because they couldn't wrap their head around Linux Audio.

Build a blackbox around it and try to rework it on the inside.

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by cycloptic on Sunday February 07, 2021 @06:35PM (#26059259)

I'm not sure what you mean. Pipewire goes out of its way to have ABI compatibility, so all your old applications using Pulse/Jack will just work.

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by account42 on Monday February 08, 2021 @09:41AM (#26065057)

What about ALSA or OSS applications?

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by cycloptic on Monday February 08, 2021 @03:02PM (#26069369)

I believe there is a pipewire ALSA module, and for OSS there are (were?) numerous ways to get that emulated in ALSA.

[ Parent | on HN ]

Re:Making Sense of the Audio Stack on Unix by account42 on Tuesday February 09, 2021 @03:42AM (#26075216)

Ok so it should not be worse than pre-PipeWire at least. Too bad Linux can't just make /dev/dsp be usable by multiple applications like the *BSDs managed.

[ Parent | on HN ]