mypasswordis1234Pipewire vs PulseAudio, general question
bloopernovaPipewire is the new hotness. I’ve read comments from various audio engineers and programmers that pipewire “gets it right”.
Pipewire came out in 2017, pulseaudio in 2004.
Audio engineer here. Anything ALSA is inherently does not “get it right”
What sort of problems have you heard of or seen? I’d like to hear your different perspective, if that’s ok with you?
This got me curious what these acronyms were. I found this information interesting.
I suspect they meant “Hardware Abstraction Layer” for “HAL”
Well if they had actually added something other than “that bad, this good” we might actually know.
I don’t think it’s entirely necessary to explain the entire topic in a simple lemmy comment about something that is so easy to search for and learn about.
uisWhich is what any OS already is.
I’m assuming it’s a complaint about how low level ALSA is compared to the, E.G. Audio HAL in Android
Well, being low level is exactly what lets to extract better performance, lower latency and other good stuff.
There’s still a fine line to draw between usability and performance
ALSA is too low level for musicians to reasonably understand
Having something like PipeWire to make it easier to configure isn’t a bad thing
People here also are asking for super low-latency
That’s another nice thing about PipeWire.
It supports configuring JACK for you if you need low latency
One person above(Audbol) want to go even lower.
You lost track of the conversation. That was about ALSA
Confetti CamouflageCan you elaborate on what specifically makes ALSA bad, and what you mean by HAL audio drivers?
I answered below, you can also read on any of the ALSA pages as well as the wiki page for it. Wealth of knowledge on the subject is available
www.alsa-project.org/alsa-doc/alsa-lib/pcm.html
After application transfers the data in the memory areas, then it must be acknowledged the end of transfer via snd_pcm_mmap_commit() function to allow the ALSA library update the pointers to ring buffer. This kind of communication is also called “zero-copy”, because the device does not require to copy the samples from application to another place in system memory.
When you tell RTFM expect to see manual stating opposite of your point.
That’s still not direct hardware, if you think you cracked the code then by all means show everyone otherwise, this would be a huge deal for a lot of people
Not direct enough? It literally says it will send your buffer to soundcard without creating any additional buffers.
Other people under this post complain of ALSA being too direct.
Nobody is
Miku Luna \ she/itNot directly answering your questions:
wiki.archlinux.org/title/PipeWire
I’m bad at describing so take the Arch wiki page.
You don’t really have to worry about configuring much, it should be fine to install all the packages, maybe enable some services, and forget about it.
It’s likely that you’re not using Arch, so you’ll have to check your distro’s repos for the packages.
Pipewire is much better than Pulseaudio, especially for pro audio work because of its low latency. Another popular option is JACK, which must be used in conjunction with Pulseaudio. Harder to set up, but is also great for pro audio. Some audio engineers were having issues with Pipewire when it first came out so they went back to using JACK, but I think Pipewire has improved. Pipewire has been flawless on my end.
If you’re not in pro audio or any kind of multimedia work, it doesn’t really matter and you can just stick with whatever comes pre-configured on your distro. But my vote goes to Pipewire as the best server for pretty much anyone.
I have had some problems with PipeWire as JACK replacement, mostly it was some tearing artifacts that were very annoying. Recently though I learned how to use PipeWire (which is great for general desktop audio usage + works with Bluetooth really good) with JACK for pro-audio applications. By using the JACK DBus detect module it is possible to turn PipeWire into JACK client when ever the latter one is started.
I’ve been running Pipewire in pro audio setup for my son and his band mates since the early days of the project. Granted I did run into some issues at first, but for a long time now it has been solid as a rock. With all of the plugins it is a joy to work with, no more Jack, Jack 2, Alsa, Pulse bridging and configuration nonsense, it all just ‘works’ now.
I would recommend it to anyone as a first option when setting up anything audio related on Linux now.
I believe that PipeWire is really solid piece of software, but I couldn’t just let go of JACK just yet. JACK just works and it’s easy to modify important parameters like sample rate or buffer size. On PipeWire I still don’t know how to quite do that, I get lost in all those configuration files, but I will get it someday.
Also one more thing that might be niche, but it’s important for me is JACK timecode (for synching i.e. a DAW with video player) which PipeWire doesn’t support at all at the moment. Getting it work on PipeWire (converting JACK timecode to LTC or MTC) gets ugly pretty quickly. So I’m glad PipeWire allows to use it however I like it, either as JACK server or client.
which must be used in conjunction with Pulseaudio
Why? Just why?
any kind of multimedia work, it doesn’t really matter and you can just stick with whatever comes pre-configured on your distro. But my vote goes to Pipewire as the best server for pretty much anyone.
Or gaming. PulseAudio has insane latency. Use JACK or no server(that means use ALSA). Maybe Pipewire has tolerable latency, but I didn’t test it myself.
narsheeWhat are other alternative popular sound servers besides these two?
ALSA; low level, not really recommended to use directly. JACK; professional audio. GStreamer; idk exactly. Pipewire supports applications using any of those.
Never had problems with pulseaudio, but pipewire solved all problems i had with Jack so best of both worlds! :)
Pipewire is really buggy for me so I just use pulseaudio.
Pulseaudio was always buggy for me. I’ve only tried pipewire recently and so far I’ve had no issues.
The only downside is that (from having to do so much troubleshooting) I know more or less how to configure and tweak pulseaudio. If I ever decide to do weird sound things with pipewire, I’m starting from scratch.
Pulseaudio will not even work on my system without bugs, pipewire was the only way for my system to have good sound.
ALSA
Pipewire fixed some Bluetooth issues for me.
Presi300Tl;Dr use pipewire, it’s just better and also handles screen capture on Wayland (which looks way better and has a much lower performance impact than X native screen capture in my experience)
donutsPipewire seems to do everything better than PulseAudio, in my experience. It's stable, compatible with PulseAudio and JACK stuff, works for low latency stuff like music production, can be routed flexibly, etc... As someone who used to run a PulseAudio+JACK stack but has since replaced both with just PipeWire, I'm a big fan.
Read xkcd. To be fair it doesn’t seem to create new audio api, but be alternative implementation.
I still recommend bare ALSA for average users.
