Hacker News Reader

Comment by squarefoot | Hacker News Reader

Patiently waiting for Linux to have one audio server that will offer compatibility to all previous ones (that is, all software requiring other audio systems such as oss, alsa, PA, Jack, etc. will be handled gracefully without installing them) while encouraging direct support for new apps, then slowly phasing them out until we have a consistent, possibly layered, low latency audio stack that scales from small single board computers to full sized audio workstations. Choice is a good thing, but too much of it can have negative effects by slowing development and porting down (see window/desktop managers).

View on HN

PipeWire is aiming, and positioned to be this service. I don't have a particular case for low-latency audio so I can't comment on that but it is amazing that you can use pavucontrol to tweak your device configuration and volumes then use qjackctl to wire the devices however you want. I'm impressed at how well it works and it even supports better bluetooth codecs than pulseaudio does.

It has already shipped by default in Fedora and is available in Arch and NixOS. It does look like it will quickly wipe out PulseAudio by default. I'm sure Jack and ALSA will hang in there longer but they are already used much more rarely (by users, the ALSA API will stick around for decades more I'm sure).

Interestingly, FreeBSD and Linux both started with the same audio stack (OSS) and both rewrote it twice[1], but FreeBSD has kept the original OSS API while adding essentially the same features, it seems.

The big selling-point of ALSA, from what I remember, was that OSS couldn't provide mixing to support multiple applications - but FreeBSD's OSS does that. Some of the main selling-points of PulseAudio are per-application volume, low latency and high-quality resampling, all of which FreeBSD's OSS claims to do as well.

[1] https://wiki.freebsd.org/Sound

The same features? Interesting. Hiw about bluetooth audio? Support for wayland?

Wayland is Linux-only.

Not true: https://wiki.freebsd.org/Graphics/Wayland

I run sway on FreeBSD and haven’t observed problems.

To be a bit more on the nose than the other replies? Did you read past the headline at all?

This is perhaps one of the best examples of not just making a new standard, but making one implementation to rule them all and implementing all the competing standards.

> Patiently waiting for Linux to have one audio server that will offer compatibility to all previous ones

That's PipeWire!

> then slowly phasing them out until we have a consistent, possibly layered, low latency audio stack that scales from small single board computers to full sized audio workstations.

Does PipeWire have its own interface for applications yet? I haven't heard of it if so. That's good; let everything maranate for a while before trying to design the "one, true interface".

Pipewire is implementing Alsa, Pulse Audio and Jack already. I don't think alsa is going away but I can see Pulse Audio and Jack being replaced by it quite quickly.

I don't think ALSA and Pipewire fill the same niche anyway? I was under the impression ALSA was an API for directly talking to the audio devices, which would be used by Pipewire or Pulseaudio or that in-house solution ChromeOS uses, or whichever flavor of mixer.

End-user applications talking directly to ALSA will probably become more uncommon, though.

Edit: Yeah, the PipeWire FAQ confirms this https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...

Pipewire indeed doesn't replace ALSA, but it provides the ALSA API, allowing applications coded against the ALSA API to use pipewire.

Ah this is very cool to hear, thanks for the clarification.

I wonder, problems with PA emulating ALSA were AFAIK always blamed on apps abusing ALSA APIs. Does Pipewire do a better job of emulating ALSA than PA did, or does Pipewire just rely on the fixes installed to make those ALSA apps start to work OK on PA?

I'm not familiar with the details of this topic, sorry. I believe PA did (or still does) publish guidelines for a 'safe' subset of the ALSA API.

Don't know if Pipewire has published something similar, but I would guess there are corner cases in the ALSA API that wouldn't work well on top of Pipewire. E.g. the buffer rewinding, considering that Pipewire is explicitly designed around never doing that.

That would be great for new software, but what about older software that doesn't know about Pipewire? Can Pipewire mimick the presence of say Pulseaudio or Jack, so that one could safely uninstall them without breaking anything? As an example, I installed Pipewire and other related packages, including pipewire-pulse, then proceeded to uninstall Pulseaudio, but the package manager complained that to continue I had to uninstall also gqrx-sdr, which is a software defined radio program that requires Pulseaudio as a dependency. In other words, to have everything working, I would still have to keep all old audio systems in place anyway, a scenario that reminds me that old xkcd cartoon about standards.

Yes as long it does not use some kind of modules. But 99% of programs can already use pipewire via the shim.

It does replace Jack and Pulse Audio as it implements its APIs. If you have pulse and pipewire running in parallel they will actually conflict.

You can still have pulseaudio installed, but you can disable its daemon or socket so it doesn't actually run.

Reply on news.ycombinator.com