5 ms·
Interesting. Wasn't Pulseaudio from their favourite "move fast and break things" developer? Did they realize they needed a better solution? (though Pipewire al
by raverbashing 4y ago
Interesting. Wasn't Pulseaudio from their favourite "move fast and break things" developer?
Did they realize they needed a better solution? (though Pipewire also deals with video)
(the point here is basically: why couldn't they fix pulseaudio?)
- dralley 4y agoPipewire solves a bunch of problems at once * low latency / pro audio * secure video streaming and desktop capture under Wayland * unification of Jack and PulseAudio ecosystems (Pipewire implements both APIs)
- Mikeb85 4y ago> Really? Wasn't Pulseaudio from their favourite "move fast and break things" developer? Probably. But the Pipewire developer is at Red Hat, and Fedora has it as default.
- krzyk 4y agoLennart Poettering is also at RedHat.
- Mikeb85 4y agoGotcha. I assume Poettering probably working mostly on systemd no? That's what I associate him with anyway.
- krzyk 4y agoNot sure, he did also pulseaudio (which is funny because I'm not a fun of either of his two most known works, systemd being the top offender for me) so he might touch something in piperwire also.
- Beltalowda 4y agoPipewire started as "Pulseaudio, but for video"; later audio features were also added. It still uses the Pulseaudio and JACK APIs and should be a "drop-in" compatible replacement for both. I don't think RedHat or anyone ever said that Pulseaudio is perfect or covers all use cases.
- kabes 4y agoYou mean lennart poettering. Also the guy behind systemd. He's a bit controversial since he goes against the Unix philosophy and isn't very nuanced in expressing his opinion, but all criticism is easy in hindsight. Pulse audio was a great improvement over what was available at the time and systemd is IMO better than any alternative it replaced.
- egberts1 4y agoBookmarked for my edification.
- GekkePrutser 4y agoThe dark patterns he used to push systemd through is another reason. Making unrelated things dependent on it. Personally I think the Linux world follows redhat way too closely. Especially since it's really IBM now. But I'm more open to pipewire because of this. Having nice people behind it is important too IMO.
- toyg 4y agoIt's not that they follow, it's that RH does the heavy lifting nobody else wants to do (since RH devs are paid).
- Mikeb85 4y agoBlame the other vendors for not doing as much as Red Hat...
- dTal 4y agoSometimes, less is more. Red Hat has an incentive to replace old, established, boring and well-known technology with new, exciting, unreliable and unfamiliar technology, because their income comes from support services.
- _abox 4y agoWell, Canonical does, to be fair. They just seem to be unsuccessful at gaining adoption. Part of this is my suspicion that they just do it to get their IP on the map (like with the snap store that only they can manage). But I would imagine that RedHat's goals are similar, after all they are a commercial entity too. Personally I don't really trust either and I lament the high level of commercial involvement in Linux. It's one of the reasons I use FreeBSD. And they are still doing very well in features. For example they had jails (real containers, not chroot) way before Linux had containers. I don't believe in "win-win scenarios" when it comes to commercialisation. In the end the commercial interests will always trump everything. I think RedHat's recent actions around CentOS are a good example of that.
- BearOso 4y agoThe idea behind Pulseaudio was fine, but the implementation was horrible. Lennart didn't have audio programming experience, and focused heavily on the bluetooth music streaming use case. Performance-wise it was awful, particularly for games since it took control of all audio. Eventually it got much better, but it still isn't very good at low latency output. Pipewire is a completely new backend written from the ground up keeping interactive use cases in mind. It implements the Pulseaudio API for compatibility, so it can be used as a drop-in replacement, but has its own extensible interface.