5 ms·

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 th

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 to do. It's also nice for monitoring while streaming and seems to have much lower latency than OBS's monitoring.

jcelerier 5y ago
Note that qjackctl's author has made qpwgraph which is a similar tool but tailored to pipewire, it works great (and is already available in e.g. ArchLinux AUR, or here otherwise: https://gitlab.freedesktop.org/rncbc/qpwgraph https://gitlab.freedesktop.org/rncbc/qpwgraph )
pimeys 5y ago
Is there a good writing about setting OBS with monitoring using Pipewire? I'd be really excited to make my Zoom streaming better with OBS.
bsder 5y ago
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?
- marcodiego 5y ago
  Some of the pipewire devs are old pulseaudio and jack devs. They are fixing their mistakes now. With a common goal, at last.
- TD-Linux 5y ago
  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).
thrwawy283 5y ago
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.
- e44858 5y ago
  A functional package manager like nixos or guix might be a good place to start.
- goosedragons 5y ago
  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.html https://guix.gnu.org/manual/en/html_node/Invoking-guix-graph...
  - thrwawy283 5y ago
    That is definitely close to what I'm thinking of. What I was trying to say is our 1st reach should be for a graph editor. Behind the scenes it may break down to a command line program, but what you'd deal with all the time is the graph editor that you can mouse around and zoom in/out on, and add/remove edges between nodes/packages. That would be a neat experience.
- 5y ago

jcelerier 5y ago

Note that qjackctl's author has made qpwgraph which is a similar tool but tailored to pipewire, it works great (and is already available in e.g. ArchLinux AUR, or here otherwise: https://gitlab.freedesktop.org/rncbc/qpwgraph https://gitlab.freedesktop.org/rncbc/qpwgraph )

pimeys 5y ago

Is there a good writing about setting OBS with monitoring using Pipewire? I'd be really excited to make my Zoom streaming better with OBS.

bsder 5y ago

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?

marcodiego 5y ago
Some of the pipewire devs are old pulseaudio and jack devs. They are fixing their mistakes now. With a common goal, at last.
TD-Linux 5y ago
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).

thrwawy283 5y ago

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.

e44858 5y ago
A functional package manager like nixos or guix might be a good place to start.
goosedragons 5y ago
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.html https://guix.gnu.org/manual/en/html_node/Invoking-guix-graph...
- thrwawy283 5y ago
  That is definitely close to what I'm thinking of. What I was trying to say is our 1st reach should be for a graph editor. Behind the scenes it may break down to a command line program, but what you'd deal with all the time is the graph editor that you can mouse around and zoom in/out on, and add/remove edges between nodes/packages. That would be a neat experience.
5y ago