Live data from Hacker News

PipeWire: A year in review and a look ahead

collabora.com

91–100 of 125 posts

Re: PipeWire: A year in review and a look ahead

#91
My switch to PipeWire on Arch has been mostly painless except for one particularly annoying bug that I haven't been able to track down yet -- when the computer is hibernated, something in the config goes wrong and I need to rerun `alsactl init` to get sound playing again.

I'm certain this has something to do with me doing a bad install and not cleaning up old config files or something, possibly with either me either using PulseWire or not using PulseWire to manage the session, but it's pretty annoying (although apparently not annoying enough to get me to debug the issue).

Otherwise, it seems to basically just work. I'd love to do more with it, but truthfully I didn't really dig into Pulse/Alsa/Jack enough initially to really notice what the benefits are, so I can't tell a difference.

One thing I'd love is for a cleaner command-line interface to handle sinks, particularly when scripting. I'm sure if I took the time I'd understand them, but I find PulseAudio's sinks really annoying to work with and to manipulate. Again, I think this is mostly just the fact that I never really dug into Linux audio too deeply before so I'm not always completely sure what's going on with it, and I'm not doing anything complicated enough for me to immediately tell a difference. In some ways I guess that's a recommendation; if I managed to get the hibernation bug fixed then this would be a totally transparent switch from my perspective. That seems kind of impressive.

Re: PipeWire: A year in review and a look ahead

#92
post #8

I have been impressed how I've been able to make arbitrarily complex audio graphs in QJackCtl and it just works. I can even activate patch bays and it forces the audio configuration and applications (even browsers) stay happy. It's impressive how it manages to support connections that require reclocking and do the needed large ratio resampling needed behind the scenes, something that PulseAudio was never really able…

Dumb question: what did the Pipewire developers do that makes it so much better than everything else on Linux?

Sound has been an absolute disaster area on Linux for decades and it seems like the Pipewire guys just flat out solved it. (I would say "suddenly", but Wim Taymans has been working on this directly for almost 7 years and worked on Gstreamer before it)

What did they do so much better and differently?

Re: PipeWire: A year in review and a look ahead

#93

Big fan of PipeWire, although I wish the tooling could work directly with PipeWire, instead of going through pactl. It's there, it's just not user-friendly. I ended up writing a tool for changing volume/muting that directly uses pw-cli: https://github.com/smasher164/pw-volume .

Agreed, at least to a certain degree :)

I never really got good with pactl or the various other interfaces, so while it's great that Pipewire is compatible with them, I was also hoping that Pipewire would mean I never needed to get comfortable with them.

If I have any criticism of Pipewire, it's that as someone who is not really interested in learning all of the quirks and weirdness of the old systems and would happily never really learn those systems except for older compatibility reasons, it's slightly weird to be running Pipewire and have all the tutorials that I've run into around it still start with, "let's learn some Pulseaudio commands".

Re: PipeWire: A year in review and a look ahead

#94
post #61
post #26

I'm not a pro user but PipeWire has been mostly great. I originally switched because of PulseAudio was causing a hissing noise on with my bluetooth headset, and switching fixed it. However, there are still two issues that I'm struggling with and haven't been able to find a definitive answer for. One is the audio sometimes randomly jitters while simply playing music. It seems this only happens when I use my bluetooth…

> One is the audio sometimes randomly jitters while simply playing music I encounter the same issue from time to time. Almost consistently reproducible when I update the kernel and the VirtualBox driver needs to be recompiled (and there's no cap for that process that it should use max X% of CPU). As pipewire is within the user session I would assume higher system load would induce some latency and cause the jitternes…

PipeWire, just like PulseAudio, uses rtkit if available. Your distro may have made it an optional dependency, so you may not have it installed.

Re: PipeWire: A year in review and a look ahead

#95

Is anybody here using pipewire to stream to a different machine on the same network? I currently use Pulseaudio to send audio from my laptop to a raspberry (with a DAC hat) connected to my hifi, but it turns out it's a pretty niche use case. So I'm looking for anybody with a similar use case who has upgraded from PA to PW and can talk about the experience.

I forward the pulseaudio socket (pipewire-pulse, to be precise) over ssh and it works fine.

Re: PipeWire: A year in review and a look ahead

#96
> WirePlumber was made the default PipeWire session manager in Fedora 35

That sounds great and all, but can someone enlighten me exactly what a session-manager is, in the context of Pipewire?

I’m using Pipewire and it works fine. But is this something I should know about? Something I can or should tweak? Or is it mainly for the distro-maintainers?

Re: PipeWire: A year in review and a look ahead

#97
post #8

I have been impressed how I've been able to make arbitrarily complex audio graphs in QJackCtl and it just works. I can even activate patch bays and it forces the audio configuration and applications (even browsers) stay happy. It's impressive how it manages to support connections that require reclocking and do the needed large ratio resampling needed behind the scenes, something that PulseAudio was never really able…

This is an aside, but I've been watching all the audio graph editor projects pop up and it's made me realize I want something like this for package management. A package maintainer should be able to specify something is a dev dependency, runtime dependency. I should be able to form a "user dependency" where I say Xwayland depends on sway - even though it doesn't. So when I remove sway it pulls out Xwayland with it. I should be able to remove dependencies within package descriptions, and see that one used to exist but has been overridden by me. I'd love to even see the history of how that graph has changed over time (step through package adds/removes). Further filter by package source to visualize the network clouds.

I want to visualize all of these dependencies as a graph, instead of trying to hamstring things together with CLI invocations. Editing the graph would invoke the package manager.

Re: PipeWire: A year in review and a look ahead

#99
post #8

I have been impressed how I've been able to make arbitrarily complex audio graphs in QJackCtl and it just works. I can even activate patch bays and it forces the audio configuration and applications (even browsers) stay happy. It's impressive how it manages to support connections that require reclocking and do the needed large ratio resampling needed behind the scenes, something that PulseAudio was never really able…

This is an aside , but I've been watching all the audio graph editor projects pop up and it's made me realize I want something like this for package management. A package maintainer should be able to specify something is a dev dependency, runtime dependency. I should be able to form a "user dependency" where I say Xwayland depends on sway - even though it doesn't. So when I remove sway it pulls out Xwayland with it.…

A functional package manager like nixos or guix might be a good place to start.

Re: PipeWire: A year in review and a look ahead

#100
post #45

Most pipewire users here seem to be arch users with access to bleeding edge releases. But how does PW work for, say, Debian/Ubuntu users?

Fedora 35 on a thinkpad, somehow pulseaudio&some new kernel version makes it so that my laptop refuses to return from suspend, until I plug it in to wall power.

I didn't have to investigate further, but there is one open bug from another user: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/13...

https://bugzilla.kernel.org/show_bug.cgi?id=214019

Otherwise pipewire has had some bugs with audio switching and firefox at the beginning, but the last month or so has been great.

Post reply on HN