439
PipeWire 1.0 Released For Managing Audio/Video Steams On The Linux Desktop
(www.phoronix.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 26 Nov 2023
439 points (99.3% liked)
Linux
48199 readers
1067 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
I've been using PipeWire this year on my Void Linux laptop & desktop. It's been mostly OK but has a few problems. For years I have been using plain ALSA (with no custom configuration) because pulseaudio causes me regular issues across multiple machines (mostly silently failing).
Pros:
Cons:
[This comment has been deleted by an automated system]
Well, how much lennart is in this thing? Not only can that predict how well it's going to work, but also how soon it'll be fixed, how responsive the 'team' will be to bug reports, how compatible it'll be with other system components AND whether 'compatibility' will be achieved before the entire OS has been systematically imported into (and badly replicated by) the project.
I don't think honestly he gets enough credit.
If you check SystemD, its a HUGE step up, which is why everyone is using it now (whereas, the old scripts had race conditions, were a pain to write and other issues). Anyone who has written both can tell you how much better things are now..
The fact this issue is happening on both Pipewire and Pulseaudio also suggests it's more likely a bug in the drivers.. It might not be obvious on ALSA directly, but that doesn't mean an issue doesn't exist there..
And honestly, the situation before PulseAudio was awful. Audio not working was a common issue, and low latency audio was the least of anyone's problems. Whereas, these days, because of Pulseaudio, even gaming is a thing now (back then, I even saw issues on tuxracer, and Unreal tournament back in the days).
In regards to setup, most distributions will handle that anyway I'm guessing. So not sure why the configuration process should matter unless you're in Arch or Slackware? As long as the distribution handles it, it shouldn't matter. It'd really a non-issue honestly.
I do a lot of middleware development and we're regularly blamed by users for bugs/problems upstream too (which is why we've now added a huge amount of enduser diagnostics/metrics in our products which has made it more obvious the issues aren't related to us). In practice, very few people have issues with Pulseaudio (I haven't seen issues since launch). Sometimes as well, keep in mind it can be the sound interface (especially if its USB)
I probably made the overlap unclear, sorry:
Eep, that's annoying. You also probably don't have direct interaction with the users most of the time (they're not your customer) which makes this worse, people in a vacuum follow each other's stories.
There might be a bias here because these problems are not persistent, ie a reboot fixes them.
That's potentially more things different distros can do differently and more issues your middleware will start getting blamed for.
Yes it's not a problem for user-friendly distros, but why does the user friendliness problem exist anywhere anyway? It's better to fix problems upstream, not downstream.
I think that's a "winners write history" situation. There were other options at the time that might have been better choices. Everyone uses it now because of Redhat and Debian being upstream to most users, desktop and corporate. I was not surprised by Redhat adopting it (it's their own product) but Debian was quite the shock.
Yes systemd is definitely a step up from traditional initscripts (oh god). In terms of simplicity, reliability and ease of configuration however it's a step below other options (like runit). I don't have distro management experience but, given the problems I've encountered with different init systems over the years, I suspect there would be less of a maintenance burden with the other options.
I'm very curious about the downvotes to this one. May I ask people's thoughts? Perhaps I'm too vague? I can put a bigger story about my experiences with various init systems in production & research if people are interested.