Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PipeWire: A year in review and a look ahead

collabora.com

Post reply on HN
Print view View original

101–110 of 125 posts

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

#101

Post by goosedragons »

thrwawy283 wrote: post #97
TD-Linux wrote: 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.…

You can visualize dependencies as a graph with Guix out of the box [1]. While you can't easily setup "user dependencies" (except by editing the package definition) you can create profiles that install packages from a manifest file so you could have a profile with a manifest with xwayland and sway and then simply remove the profile if not needed. Guix already specifies runtime/dev dependencies.

[1]: https://guix.gnu.org/manual/en/html_node/Invoking-guix-graph...

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

#102

Post by hjanssen »

zibzab wrote: 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?

Currently using pipewire on Ubuntu 21.10 via the ppa (which is linked in another comment here).

Experience has been flawless until now. Its truly an outstanding piece of software that "just works" and gets out of your way. I am really, really happy to use it, it has simplified so many things in my day to day life.

Before, using pulseaudio, connecting my bluetooth headset and getting any application to work with it was a serious pain, now it is a matter of turning the headset on and boom, connected, all audio switches automagically over to the headset.

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

#103

Post by spear »

stncls wrote: post #81
kn100 wrote: post #35

As someone who has a fairly basic use case for something like Pipewire - I switched to it about a year ago and hope to never switch back. Everything just works properly - and some of the value added stuff we have now (Easyeffects inside a Flatpak sandbox comes to mind) are very cool and work extremely well. My thanks to the developers, who have done an AMAZING job of building a realistic alternative. There is a lot o…

> Everything just works properly Not to mention the drastically lower CPU usage compared to its predecessor [1] and general lack of bugs. > There is a lot of REALLY good software coming out Agreed, but I would still single out PipeWire as being particularly outstanding. None of the other examples are as new, or as uncontroversial. Anecdotically, when I look at the comment section of any PipeWire article here, I see b…

Yeah, that's why I switched my Fedora systems to Pipewire before it became the default. At some point, Pulseaudio CPU usage went up so much that the fans on even my desktop system were noticeably spinning up. Maybe it was a Pulseaudio regression that was eventually fixed but I never looked back.

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

#104

Post by Arnavion »

smasher164 wrote: post #67

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 .

You can also munge the pw-dump output with jq, instead of needing something to be compiled.

    pw-dump | jq '
        (
            .[] |
            select(.type == "PipeWire:Interface:Metadata") |
            (.metadata // [])[] |
            select(.key == "default.audio.sink") |
            .value.name
        ) as $default_sink_node_name |
        .[] |
        select(.info.props["node.name"] == $default_sink_node_name) as $default_sink_node |
        .
    '

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

#105

Post by TD-Linux »

bsder wrote: post #92
TD-Linux wrote: 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?

In my case, the big advantage is the automatic insertion of resamplers between different clock domains, meaning you can connect anything to anything. Pulseaudio tries really hard to make sure there is only one clock driving any connection graph, so that's why there's no arbitrary connection support without loading things like module-loopback that add the resampling themselves.

Another thing that helps is that in some ways PipeWire is less featureful than PA. For example, it limits the max audio buffer size to ~180ms which means it doesn't have to implement rewinds, one of the buggier features of PA (with the downside that power consumption can't ever be quite as low as PA).

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

#106

Post by Arnavion »

thrwawy283 wrote: post #97
TD-Linux wrote: 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.…

The standard way of doing this is to define your own package for what you want installed on the system. Check in the package spec to version control and it gives you the history of everything you wanted in the past. For your sway-xwayland case, make another package that depends on both, and make that a dependency of your system package instead of sway and xwayland directly.

You will also need to use your package manager's method of marking all packages as "automatically installed" except for your system package. How easy this is depends on the package manager. Eg for Alpine's apk this is trivial, because all packages are "automatically installed" unless they're listed in /etc/apk/world, but for OpenSUSE's zypper you need to update /var/lib/zypp/AutoInstalled to include every installed package and periodically refresh it when zypper decided to switch an automatically-installed package to manually-installed for some reason.

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

#107

Post by TD-Linux »

jancsika wrote: post #90
jabl wrote: post #25

Earlier quoted context omitted.

5. Pipewire doesn't use buffer rewinding, which was a rich source of complexity and bugs not only in PulseAudio, but also exposed bugs in the kernel audio device drivers. And even bugs or poorly specified behavior in HW itself, considering AFAIU neither macOS, Windows (nor Jack) use rewinding.

The PA docs claim that buffer rewinding is used to achieve low-latency updates to a high-latency stream. E.g., user wants to change volume now on some music that has a 2 second buffer. Seems like a common use case. How does Pipewire deal with this? Also-- links to the audio driver bug reports, please! Also-- links to info on the hardware bugs, please! I believe you, I just want to read about them.

>How does Pipewire deal with this?

It doesn't, it sets a much shorter max buffer length so that the latency is always acceptable. This does mean that in theory, with an otherwise totally idle system, PipeWire can't be quite as low power as PA.

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

#109

Post by yjftsjthsd-h »

thrwawy283 wrote: post #97
TD-Linux wrote: 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 think Alpine can do what you're asking for using virtual packages (which is basically just a label that you apply to say "the following packages are a group to be installed and removed together"): https://docs.alpinelinux.org/user-handbook/0.1a/Working/apk....

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

#110

Post by yjftsjthsd-h »

Arnavion wrote: post #95
kirenida wrote: post #30

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.

Could you share the command to do that? I've seen `foo | ssh bar`; is it just `source | ssh 'cat >/path/to/pipe'`?
Post reply on HN