[viraptor]

While pipewire still needs a lot of work and some people will see regressions in their workflow, this change is so much better than the pulseaudio disaster.

It already enables things like more reasonable Bluetooth access, BT codec/profile switching, close to real-time audio, etc. With updated pipewire you can run jack applications like guitarix and ardour and they just work. With pipewire updated from copr repositories and iRig I can use guitarix OOTB and the delay is low enough to ignore.

I can also watch movies with audio going over Bluetooth - pulseaudio had 400+ms delay, pipewire is pretty much synced up. (That's on standard codecs, not aptx) It's better than what either windows or Mac can achieve here.

[mod50ack]

If it can be useful for anyone, I've been maintaining this COPR for Pipewire (from upstream Fedora, but the patches come a bit quicker to this). https://copr.fedorainfracloud.org/coprs/dbenjaminmiller/pipe...

Pipewire was way rockier even a few months ago. It's gotten quite good especially since 0.3.25.

Ed. mfrey also has a copr with a nightly build. But this is unstable, obviously. My copr just has release builds.

[throwaway74737]

In 34, I've seen a problem with Ardour accessing the JACK API in Pipewire. Apparently one of the API calls is not implemented, which makes Ardour crash from time to time. Sadly, this means I am not comfortable using a completely free/open-source audio production platform yet.

[throwaway74737]

Downvotes are really getting out of hand on this site. It's like a person cannot even express slight negativity. I _want_ to have a completely FOSS audio production stack. I beta-tested Fedora and found a showstopper, which means I need to stick to MacOS for my audio work for the time being. Somebody thinks this means my comment is invalid.

[viraptor]

Yup, there's still some things missing. Freewheeling is one of them which makes exports from ardour get stuck. But that's in progress upstream.

[oblio]

I don't get this, does Pipewire work on its own? If it's just another audio layer in the way, how can it work better than just PulseAudio alone? (i.e. Pipewire + PulseAudio vs just PulseAudio)

[jeroenhd]

Pipewire works on its own but has plugins that allow it to mimic the PulseAudio API (as well as others, such as JACK). This makes it compatible with the applications that don't directly integrate with PW.

It's an alternative audio subsystem with a design that is a mix of Pulse and JACK features/architectures. It generally seems to have lower latencies than Pulse but higher latencies than JACK.

[m463]

I've heard so many good things about pipewire, they should really get the pipewire guy to refactor systemd too :)

[viraptor]

Pipewire uses a different architecture than pulseaudio. It's basically "we learned lots of things from low-latency video, let's apply that everywhere", not a refactor.

What do you want to change in systemd specificaly?

[m463]

one bit of relevant information to add to my comment:

The guy who wrote pulseaudio also designed systemd.

Since pipewire seems to get rave reviews, and pulseaudio grumbles... a natural train of thought would be - get the guy who wrote pipewire to take a stab at systemd.

As to specific systemd changes, I would love if someone:

- Make the systemd config files more intuitive. While the old /etc/init.d/foo files contained arguably too much logic, the systemd service files are stupid enough that logic frequently has to be pushed into (and hidden inside) a daemon.

change the awful directory structure/files/links to something more elegant and organized It's like they threw them all in one directory, and simultaneously sharded them across /etc /lib etc

status commands/journalctl/binary log files. ugh.

How has it absorbed so much into itself?

It's become a little like busybox - making an analogy here - where it absorbs tried-and-true utilities and replaces them with "good enough" that... isn't. One example might be NTP which does time sort of poorly. Yes ntp is crufty, but it does time extremely well.

[viraptor]

> a natural train of thought would be - get the guy who wrote pipewire to take a stab at systemd.

Alternative train of thought - Pottering was not great with low latency stream processing, but someone else was. Why expect the people who are good with low latency stream processing to be good with low-level process management? People have different skills/interests.

[nix23]

>this change is so much better than the pulseaudio disaster.

Cant wait until we say the same about systemd.