- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
PipeWire 0.3.77 (2023-08-04)
This is a quick bugfix release that is API and ABI compatible with previous 0.3.x releases.
Highlights
- Fix a bug in ALSA source where the available number of samples was miscaluclated and resulted in xruns in some cases.
- A new L permission was added to make it possible to force a link between nodes even when the nodes can’t see each other.
- The VBAN module now supports midi send and receive as well.
- Many cleanups and small fixes.
Removed by mod
I am shocked that Lennart Poettering, PulseAudio dev, but also Avahi and SystemD dev, whose name might frequently be brought up in conversations about interoperability, reliability, small ego, diplomacy, etc etc, might not be as good at coding an audio stack as legendary C64 demo coder and PipeWire dev Wim Taymans. Shocked, I tell you. Well, not that shocked.
Let’s be fair here. PipeWire is leaps and bounds ahead of pulse and I was super happy when I could drop pulse. But pulse predates PipeWire by a decade and introduced concepts that were previously rather complex in Linux. It’s no coincidence its interface was adopted so quickly by audio tools and that it’s the recommended interface for PipeWire today (until devs are comfortable with recommending their own). Lennart saw the need and provided a solution which, in retrospective, could be much improved - but until PipeWire, nobody put in the work.
I too had my fair share of issues with PA. But it also solved some fundamental ones for me. I don’t miss meddling with .asoundrc or whatever it was to get dmix working. Pulse should not be measured against PipeWire, but rather ALSA, OSS and the stuff that the DEs brought with them (aRts…). It wasn’t always pretty. Early Pulse, however, wasn’t either.
Also, audio was originally not even in scope for PipeWire - it was touted as “PulseAudio for video”. So pulse didn’t exactly have a bad reputation even among PipeWire devs.
understandably, audio and graphics are different whole beast to manage, i guess
I didn’t even know Avahi is his project too, but was avoiding it too. Crazy how one person can create so many bad but popular projects.
I am curious, why is Avahi considered bad? Never used it so I am unfamiliar with the topic.
I have no idea, but on gentoo there is a use flag avahi and whenever I tried to enable it, it pulled so many dependencies I always blocked it.
I’ve read before that Pulse really had a difficult challenge, since it had to really resolve a lot of hardware vendor quirks that essentially would never be resolved. PipeWire gets the advantage of not having those early growing pains, because Pulse went through them. I’m not involved with the development of either to really know one way or another the truth behind that story.
Removed by mod
Sounds reasonable to me. The day only has so much hours. Software engineering is always a story of trade-offs, isn’t it?
Why do you think these issues have nothing to do with drivers? Apart from confusing controls, all of these can be attributed to hardware and driver quirks.
Removed by mod
All of the following is speculation on my side and just stated as fact for easier reading / writing.
Because it did not allow for the functionality that exposed those bugs (as in PulseAudio provided features that should work according to documentation, but didn’t)
Because these bugs got fixed after PulseAudio exposed them.
Removed by mod
Have it your way dude, I ditched PulseAudio for PipeWire over two years ago (see my post at https://www.reddit.com/r/linux_gaming/comments/kufrmu/pipewire_audio_is_so_good_now/) and never looked back. But I strongly believe that PulseAudio, despite its flaws, was an overall gain for Linux audio and I dislike people bashing the work of others.