Pipewire, Jack Applications & Low-Latency tuning for soundcards

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

asbak
Established Member
Posts: 897
Joined: Thu Sep 11, 2014 3:04 pm
Has thanked: 71 times
Been thanked: 64 times

Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by asbak »

I've set up a Mint 21 (Jammy 22.04) laptop for general purpose use & music production and decided to try out pipewire.
A 5.19 Low Latency Kernel was installed. You probably need to be on at least a 5.14 Kernel. I probably need to move to a 6.x kernel myself.

An additional motivator for using pipewire was that there is a PPA available which provides bluetooth AAC codecs and boy, does that improve the sound in a set of compatible headphones that supports AAC, but I digress.....

The system has been set up to allow switching to pulse & jack from pipewire, if required. Disabling pipewire loses the nice bluetooth audio but that gets me back to pure Jack & ALSA, when required.

The challenge was trying to get soundcards work well under pipewire with low-ish latency. Pipewire configs don't appear to deliver low-latency operation straight out of the box, at least not for me.

An ultimate low-latency setup runs on ALSA without pulse, jack & pipewire but a person loses some flexibility with regards to consumer audio & routing options. I get the feeling that latency is not as good with pipewire as it is with Jack on ALSA, or with ALSA only. At least not for me, but what do I know. And I know next to nothing about Pipewire and trying to make sense of how it works has been a real struggle.

Here's what seems to work for me to tune soundcards to run at somewhat lower latencies without the dreaded xruns.

Please note, this is not a comprehensive sound system installation & configuration & tuning guide. I'm focusing on "pipewire tuning" only in this post.
Setup & installation & configuration & tuning of a Linux audio system isn't covered here. You'll have to take care of that yourselves.

System: Thinkpad
OS: Mint 21, similar to Jammy 22.04 (I wouldn't install Ubuntu, personally. Who needs snap in their life.)
Audio: Pipewire with Wireplumber.
Soundcards tested: Edirol UA-25, Edirol UA-101, MOTU Traveler, Intel internal PCI audio.

I'm assuming a fresh Pipewire / Wireplumber setup, if not "fresh", you may need to re-install or re-initialise it somehow if you haven't kept track of changes you may have made.

Needless to say, perform everything below at your own risk, if your system breaks for whatever reason that's on you.
A reminder, this is for a Mint 21 / Jammy 22.04 environment. Other distributions may function differently.

Wireplumber Configuration files:

ALSA:

sudo cp /usr/share/doc/pipewire/examples/alsa.conf.d/99-pipewire-default.conf /etc/alsa/conf.d/

JACK:

sudo cp /usr/share/doc/pipewire/examples/ld.so.conf.d/pipewire-jack-*.conf /etc/ld.so.conf.d/
sudo ldconfig -v

Pipewire config, as your local user:

mkdir -p ~/.config/pipewire/
cp /usr/share/pipewire/*.conf ~/.config/pipewire/

In Mint 21 (and Ubuntu 22?) you'll need to create a pipewire group and add your user as a member.

sudo groupadd -g 200 pipewire
usermod -a -G pipewire <your user>

Then set pw parameters in /etc/security/limits.conf

Code: Select all

@pipewire - rtprio 95
@pipewire - memlock 4194304
@pipewire - priority -19

Edit the following files under ~/.config/pipewire/

minimal.conf
pipewire.conf
jack.conf

Uncomment and change values for ~/.config/pipewire/ node.quantum & default.clock.quantum to 256

node.quantum = 256/48000
default.clock.quantum = 256

The magic appears to happen in the /usr/share/wireplumber/main.lua.d/ folder where you can add customised lua configurations for your soundcard.

The magic pipewire values - which usually seemed to work best for my situation - appeared to be as follows:

["api.alsa.period-size"] = 256,
["api.alsa.period-num"] = 3,

On to the soundcard configurations. Create new lua config files and paste the values below for the following soundcards.

You'll have to check the node.name values for your particular devices and modify if required.

Motu Traveler
sudo vi /usr/share/wireplumber/main.lua.d/51-fw-traveler-config.lua

Code: Select all

rule = {
  matches = {
    {
      -- Matches all sources.
      { "node.name", "matches", "alsa_input.firewire-0x0001f20000020b81.*" },
    },
    {
      -- Matches all sinks.
      { "node.name", "matches", "alsa_output.firewire-0x0001f20000020b81.*" },
    },
  },
  apply_properties = {
    ["api.alsa.period-size"]   = 256,
    ["api.alsa.period-num"]    = 3,
  },
}

table.insert(alsa_monitor.rules, rule)

Edirol UA-25
sudo vi /usr/share/wireplumber/main.lua.d/52-usb-ua25-config.lua

Code: Select all

rule = {
  matches = {
    {
      -- Matches all sources.
      { "node.name", "matches", "alsa_input.usb-Roland_EDIROL_UA-25-00.*" },
    },
    {
      -- Matches all sinks.
      { "node.name", "matches", "alsa_output.usb-Roland_EDIROL_UA-25-00.*" },
    },
  },
  apply_properties = {
    ["api.alsa.period-size"]   = 256,
    ["api.alsa.period-num"]    = 3,
  },
}

table.insert(alsa_monitor.rules, rule)

Intel Internal PCI Soundcard
sudo vi /usr/share/wireplumber/main.lua.d/53-pci-intel-config.lua

Code: Select all

rule = {
  matches = {
    {
      -- Matches all sources.
      { "node.name", "matches", "alsa_input.pci-0000_00_1f.3.*" },
    },
    {
      -- Matches all sinks.
      { "node.name", "matches", "alsa_output.pci-0000_00_1f.3.*" },
    },
  },
  apply_properties = {
    ["api.alsa.period-size"]   = 256,
    ["api.alsa.period-num"]    = 3,
  },
}

table.insert(alsa_monitor.rules, rule)

EDIROL UA-101
Note that the period number for the UA-101 was set to 5 because lower values produced xruns.

sudo vi /usr/share/wireplumber/main.lua.d/54-usb-ua101-config.lua

Code: Select all

rule = {
  matches = {
    {
      -- Matches all sources.
      { "node.name", "matches", "alsa_input.usb-EDIROL_UA-101_*.*" },
    },
    {
      -- Matches all sinks.
      { "node.name", "matches", "alsa_output.usb-EDIROL_UA-101_*.*" },
    },
  },
  apply_properties = {
    ["api.alsa.period-size"]   = 256,
    ["api.alsa.period-num"]    = 5,
  },
}

table.insert(alsa_monitor.rules, rule)

Please add any additional useful tips, suggestions, configuration tricks for pipewire that you may know about below.

Last edited by asbak on Wed Mar 22, 2023 8:59 am, edited 4 times in total.
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
User avatar
sunrat
Established Member
Posts: 907
Joined: Wed Jul 22, 2020 2:08 pm
Has thanked: 151 times
Been thanked: 238 times

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by sunrat »

Did you try any lower period size than 256?

salve
Established Member
Posts: 7
Joined: Sun Jan 29, 2023 8:19 am
Been thanked: 1 time

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by salve »

asbak,
this seems sooo cracy complicated. I don't know Mint or Ubuntu for that matter. I just want to say that the switch to pipewire on Debian testing (bookworm) is so much easier than this. It might work smoother for you to just try that?

asbak
Established Member
Posts: 897
Joined: Thu Sep 11, 2014 3:04 pm
Has thanked: 71 times
Been thanked: 64 times

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by asbak »

sunrat wrote: Fri Mar 17, 2023 9:38 pm

Did you try any lower period size than 256?

Didn't work for me. I don't know much about Pipewire at this stage.

In pure Jack / Alsa (Pipewire off) I can get lower. *Couldn't find a way to get it to work w. lower settings in Pipewire.

If you have any suggestions on how to improve the tuning I'd be most interested. It's extremely difficult to find reliable, up to date and sensical information about the topic. Most of it seems obscure, way over my head or buried in bug report posts.

*To expand on that, yes I could get lower settings to run in some cases, but not reliably. My criteria was to throw a taxing workload on the system where things worked without xrunning. Under those conditions, those were the lowest settings I could get to run reliably so far.

More testing still needed to confirm how reliable it really is.

Last edited by asbak on Sat Mar 18, 2023 2:07 am, edited 2 times in total.
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
asbak
Established Member
Posts: 897
Joined: Thu Sep 11, 2014 3:04 pm
Has thanked: 71 times
Been thanked: 64 times

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by asbak »

salve wrote: Fri Mar 17, 2023 9:42 pm

asbak,
this seems sooo cracy complicated. I don't know Mint or Ubuntu for that matter. I just want to say that the switch to pipewire on Debian testing (bookworm) is so much easier than this. It might work smoother for you to just try that?

Yes you're right, it is crazy complicated. Too crazy. What was I thinking.
Debian is the answer you are 100% correct my friend.

Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
User avatar
GMaq
Established Member
Posts: 2768
Joined: Fri Sep 25, 2009 1:42 pm
Has thanked: 518 times
Been thanked: 555 times

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by GMaq »

Hi,

I keep coming back to the same question about PipeWire...

As someone primarily doing AV Work with a good and proven JACK/Pulse set up and most of the time using Ardour or Mixbus direct to ALSA what real benefit is there to PipeWire? There are already long-running issues with how low latency can go... I'd have to launch JACK apps with customized commands...? No established GUI settings for Sample Rate and Buffers..? JACK and the PulseAudio JACK modules allow me to pretty much route anything to anywhere, the system is optimized out of the box and with the exception of maybe modifying /etc/default/rtirq to prefer USB Audio devices there is no configurations needing to be touched..

I'm starting to test AV Linux builds on Debian Bookworm and integrating PipeWire 'just because" isn't a good enough reason to tear out a mature working system, sorry but I don't see much here yet except a re-invented wheel with just as many bent spokes as the one it purports to replace... Unless something pretty major changes or improves or unless it become impossible to proceed without it (I'm banking on this being quite likely) I won't be getting on the bandwagon in the near future..

User avatar
sunrat
Established Member
Posts: 907
Joined: Wed Jul 22, 2020 2:08 pm
Has thanked: 151 times
Been thanked: 238 times

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by sunrat »

I'm tending to agree with you there @GMaq . I can play guitar while monitoring in headphones at 128/2 but any more latency than that is noticeable.
I think somehow Pipewire will be able to do lower than that but the special sauce to achieve it is still secret afaik.

j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by j_e_f_f_g »

GMaq wrote: Sat Mar 18, 2023 3:11 am

what real benefit is there to PipeWire?

None whatsoever for musicians. In fact, in terms of performance, it's a step backward for pro-audio use.

The entire purpose of Pipewire is to re-invent PulseAudio, but this time design into it the capability to sync video to audio. PulseAudio was designed to be a generic "high level" audio API for developers writing programs where audio wasn't a critical feature. Examples would be browsers, games, any program that needs to play sound effects, etc. It wasn't designed for pro-audio apps such as DAWs, audio editors, MIDI apps, etc. Unlike ALSA, Pulse defaults to "mixing" the audio outputs of numerous simultaneously-running apps, in realtime, including audio at various bit resolutions and sample rates. As such, it provided a necessary, system-wide, shared audio system for developers of GUI/desktop apps, which was easy to use, albeit not suitable for low-latency pro audio tasks. (It was "good enough" for most PC apps.)

But it omitted features useful to developers needing to stream audio in sync with video. So the guy who designed a popular video streaming library (gstreamer) decided to re-implement a high-level combination video plus audio system (of which Pipewire is the audio part). It's never going to perform better than Alsa, or even jack. But it's going to be used like Pulse Audio has been, that is, by devs writing generic PC software that happens to make sound. It will be good enough for that sort of use.

Musicians trying to setup Pipewire to yield similiar performance as Alsa, or even jack, are wasting their time. It isn't designed to do that, and it won't ever do so.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

asbak
Established Member
Posts: 897
Joined: Thu Sep 11, 2014 3:04 pm
Has thanked: 71 times
Been thanked: 64 times

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by asbak »

GMaq wrote: Sat Mar 18, 2023 3:11 am

Hi,

I keep coming back to the same question about PipeWire...

As someone primarily doing AV Work with a good and proven JACK/Pulse set up and most of the time using Ardour or Mixbus direct to ALSA what real benefit is there to PipeWire? There are already long-running issues with how low latency can go...

Based on what I've tried (which isn't much, granted), I'm in total agreement with you.

Based on my limited experience with Pipewire I have the perception (disclaimer: I'm not the world's #1 DAW optimiser and surely don't have the best tuned machine) that Pipewire is outperformed in the latency stakes by JACK + ALSA.

I do have the perception (could be wrong, and this is in the hands of the gods to determine), that there are slow improvements & code updates coming down the line, and that the developers are aware of some of these issues and have set longer term goals to re-write some code to improve performance.

Why pipewire? Well, it would be nice to get to a point some day where most things just work out of the box, or at least, work a lot better out of the box than they currently do.

And not having to rely on homebrew solutions (which work fine, but it's a drag to have to use and there's a performance hit) with pulseaudio on jack would be nice. Yes I know, I can play a youtube video via pulse and run it on top of jack but with pipewire I don't need to do this anymore since Pipewire now handles pulse and consumer audio instead.

I'd have to launch JACK apps with customized commands...?

With the changes I made above - and based on limited testing so far - I am not using any customised commands to run jack plugin hosts or audio production software / sequencers or Guitarix. I just start a host and go. I can see the period & buffer sizes in the soundcard hw_params and they don't look too bad with a Period size of 128 of and a buffer size of 640 for a UA-101 @ 48kHz.

On another system running JACK + ALSA I see a Period size of 128 and Buffer size of 384 in hw_params, which is slightly better but not by a whole lot. Yes JACK + ALSA system could probably be set to a lower latency but at lower settings the likelyhood & risk of Xruns increase.

I haven't measured the latency because I don't know how, LOL, and tbh I don't really care about winning a pissing contest. What matters is what I hear & experience between pressing a key or playing a chord. My ears are telling I'm in at least 10ms - 20ms ballpark territory which isn't too bad. It may even be slightly better but until I understand how to measure it I just don't know.

I'll have a go with a guitar later as latency's a lot more noticeable than with a keyboard.

No established GUI settings for Sample Rate and Buffers..?

Alas not that I'm aware of, lol :mrgreen:
It's all about hacking confusing & esoteric configs which differ depending on Pipewire version, distro, which session manager is used, how the stars were aligned when configuration notes were written and more. It's a very confusing picture which is why I started this topic. To learn from those who know much more about it than myself. I just got the ball rolling on this issue which is near and dear to me.

JACK and the PulseAudio JACK modules allow me to pretty much route anything to anywhere, the system is optimized out of the box and with the exception of maybe modifying /etc/default/rtirq to prefer USB Audio devices there is no configurations needing to be touched..

You're luckier than me then, there's no end to the amount of configs I've modded or had to mod on my newly installed box. (Disclaimer: Many aren't necessarily for Pipewire.)

I'm starting to test AV Linux builds on Debian Bookworm and integrating PipeWire 'just because" isn't a good enough reason to tear out a mature working system, sorry but I don't see much here yet except a re-invented wheel with just as many bent spokes as the one it purports to replace... Unless something pretty major changes or improves or unless it become impossible to proceed without it (I'm banking on this being quite likely) I won't be getting on the bandwagon in the near future..

Yes you do you, Pipewire isn't for everybody for sure and AV Linux is after all focused on a specific workflow and usage case scenario.

  • My standards are simply lower :mrgreen: , I'm much more flexible, less dogmatic and my usage requirements and user case scenario is different.

  • When or if I need to switch to pure ALSA + JACK (and maybe Pulse), well, I can do it easily and quickly with a few commands or a script. Therefore, whatever issues Pipewire may have are effectively a non-issue for myself because I can work-around it when required.

  • My bluetooth headphones + AAC codecs work great with Pipewire, none of this messing around with connection problems or iffy sounding codecs.
    Just to be clear, due to latency characteristics with BT I'm not suggesting to use bluetooth headphones for Audio Production!!! I meant to say that they now work well for CONSUMER audio purposes on my Mint 21 box.

  • For my usage needs, keyboard audio is already acceptable. I accept and agree I can go lower with JACK + ALSA but there's a law of diminishing returns here. The performance gains aren't massive or a deal-breaker compared to what I can now get with Pipewire.

  • Guitar testing still remains to be done, this may be more of an issue if there's too much latency. Can't comment on that yet.

  • I am kind of trying to get close to the "It's a Mac, it just works" Desktop Computing experience. I detest Apple Corporation but nevertheless it would be nice if I could build a general purpose system that can perform roadwarrior functions, offers normal Desktop Computing possibilities AND also works as an acceptable DAW.

  • This way I kind of keep my options open. I can use Pipewire for most usage case scenarios, and if the situation demands a JACK + ALSA solution I can semi-seamlessly switch to that as well.

I couldn't find well publicised, recent, up-to-date or readily accessible and understandable info out there for getting Pipewire to run with more musician friendly parameters which is why I started this topic.

For those who don't like, want or see the need for Pipewire, I totally get it. It's not for you and that's OK! Nevertheless, for scallywags and brigands such as myself, Pipewire perhaps has something to offer. If that's YOU, I'd <3 to hear from you and learn from your experiences, pretty please. :D

Just to confirm again, imo JACK +ALSA is definitely still the way for the ultimate in audio production performance. However, it looks like more Pipewire code improvements are coming (eventually) after which current performance differences should hopefully become negligible.

Based on how my system's currently running (tested with a resource hungry plugin that loves xrunning untuned systems) it seems solid so far.
Guitar testing next (and yeah.... latency is probably going to be a bit worse than what I can reliably get (no xrunning) with JACK + ALSA).

Any additional tips / tricks / methods that anybody knows about to get latency down lower !!!!WITHOUT XRUNNING!!!!, please add them.

If any of our resident experts know of better values to plug in (I honestly don't really understand how many of them actually work in Pipewire), and where to plug them in, please share. :D

Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
asbak
Established Member
Posts: 897
Joined: Thu Sep 11, 2014 3:04 pm
Has thanked: 71 times
Been thanked: 64 times

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by asbak »

Performed another round of configuration optimisations, tested with a guitar.
Latency's low enough (on one of the soundcards) for me to not notice it on nearby monitors or headphones. Mileage for others may vary.

I ran a youtube video, a very CPU hungry synth plugin and Guitarix at the same time, no xruns.

Best of all, CPUFreq governor was set to "powersave" the whole time, so the laptop ran cool & quiet. That's not to say one shouldn't use "Performance" but in this case, for casual use, it wasn't necessary.

It looks like most of the stars finally aligned and a combination of factors (newer kernels, ALSA driver improvements, later versions of pipewire, luckier tuning options & me making less tuning mistakes & omissions) have converged to finally produce a good all round solution that can handle both daily driver tasks & audio well. I couldn't be happier.

  • I couldn't perceive latency on keyboard or guitar (and yes I'm getting old, so what I miss may be recognised by others).
  • There weren't any xruns during the casual session with a CPU hungry synth plugin, guitarix & consumer audio running at the same time. (OK, I didn't try to play an orchestral arrangement loaded with plugins in a sequencer but that's really a different usage case scenario anyway.)
  • CPUFreq governor didn't need to be switched to "Performance" for the casual session.
  • Laptop WIFI was on, and didn't cause xruns.
  • Browser was playing youtube videos, didn't cause xruns.
  • I don't need to switch back and forth between Pulse, Jack, route Pulse through Jack anymore.
  • Pulseaudio consumer audio will "just work" in Pipewire.
  • Consumer bluetooth headphones work, no switching back & forth required.

More testing on more hardware and over longer periods is still required but this seems to be it for me, the holy grail. Finally.
I acknowledge there's a lack of round trip latency testing figures and that ALSA & JACK would almost certainly achieve better results, but nevertheless, the system as currently configured appears to be good enough for my personal requirements.

What's next?
For a grand finale, perhaps get yabridge & Wine set up and have yet another go at getting Windows VST's (mostly) working, without the usual caveats, disappointments and xruns.

BTW, the instructions up top have been modified slightly.

For minimal.conf, pipewire.conf, jack.conf, also uncomment the "context.modules" parameters for rt.prio, rt.time.soft, rt.time.hard and nice.level.
Whether or not this has much effect to mitigate against xruns in my case I couldn't say for sure, but at least it doesn't appear to make matters worse.

Code: Select all

  
nice.level = -11 rt.prio = 88 rt.time.soft = -1 rt.time.hard = -1

This may require RTKit installed & correctly set up if you don't already have permissions to use regular realtime scheduling. (According to the comments in the conf files.)

Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by j_e_f_f_g »

the system as currently configured appears to be good enough for my personal requirements

And only you can determine that.

But just be aware that Pipewire will never give you the latency you can reduce to via ALSA, or even jack. Pipewire isn't designed for that. Unlike ALSA/JACK, Pipewire is designed to be an audio mixer that accepts multiple audio signals, in any combination of sample rates and bit resolutions, and can sync it to video playback. This is very different than ALSA or jack. You'll just waste time (or worse, break your OS) if you keep trying to get it to match alsa/jack.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

nils
Established Member
Posts: 536
Joined: Wed Oct 22, 2008 9:05 pm
Has thanked: 35 times
Been thanked: 94 times
Contact:

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by nils »

j_e_f_f_g wrote: Sat Mar 18, 2023 2:27 pm

the system as currently configured appears to be good enough for my personal requirements

And only you can determine that.

But just be aware that Pipewire will never give you the latency you can reduce to via ALSA, or even jack. Pipewire isn't designed for that. Unlike ALSA/JACK, Pipewire is designed to be an audio mixer that accepts multiple audio signals, in any combination of sample rates and bit resolutions, and can sync it to video playback. This is very different than ALSA or jack. You'll just waste time (or worse, break your OS) if you keep trying to get it to match alsa/jack.

While I don't productively use, or even like, Pipewire personally -for multiple reasons- what jeffg says is not really true.

Pipewire is indeed a pulseaudio replacement, but it also wants to be a jack replacement. There is a jack-similar server behind the scenes that is theoretically capable of running with low-latency, as does JACK. In fact Pipewire (minus bugs and TODOs) is JACK ABI and API compatible.

j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by j_e_f_f_g »

nils wrote:

Pipewire wants to be a jack replacement

It may be billed as such, but as is so often true, there's a big difference between theory and reality. Pipewire is a "compatible replacement" with Jack in the same way that a horse and buggy is a compatible replacement for a race car. Just like the racecar, the buggy can transport you from one location to another. But in practice, they are two significantly different things with more differences than similiarities.

Pipewire's audio processing is a completely different codebase than Jack's. The former isn't designed to prioritize low latency. It prioritizes the mixing of various formats, sync audio to video, and a simpler, generic API for ordinary desktop apps. Folks who expect it to yield the same performance as ALSA/JACK are certain to be disappointed. I would think that, by now, linux audio enthusiasts would have seen enough of these alsa/jack "replacements" to realize that all the promises of "this is as good as, and completely replaces, alsa/jack" conveniently omits the matter of pro-audio standards for performance. In a nutshell, this stuff isn't designed for that. So let's not setup linux musicians for yet more disillusionment after they realize that they've been misled in their expectations yet again.

Pipewire ain't Jack3 or Alsa2. It's more like PulseAudio2.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

User avatar
GMaq
Established Member
Posts: 2768
Joined: Fri Sep 25, 2009 1:42 pm
Has thanked: 518 times
Been thanked: 555 times

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by GMaq »

@asbak

Thanks for sharing your info and settings that's very helpful especially for those who already have PW on the system or are installing Mint or other popular systems renowned to be excellent general Linux Desktop systems. Actually my apologies for popping up with an opinion post that really derailed your initial useful intentions, I didn't really think it through..

Last edited by GMaq on Sat Mar 18, 2023 4:31 pm, edited 1 time in total.
nils
Established Member
Posts: 536
Joined: Wed Oct 22, 2008 9:05 pm
Has thanked: 35 times
Been thanked: 94 times
Contact:

Re: Pipewire, Jack Applications & Low-Latency tuning for soundcards

Post by nils »

j_e_f_f_g wrote: Sat Mar 18, 2023 3:59 pm

Pipewire ain't Jack3 or Alsa2. It's more like PulseAudio2.

Absolutely.
And the number of posts and questions about problems how to configure pipewire for low latency rivals that of JACK over the years. Except that Pipewire is marketed as "this will solve all these problems those anti-user-experience guys from alsa and jack were not able to see and solve" while JACK never was.

Because the pipewire answers are still based around config files editing in a terminal. Turns out the pipewire devs are linux nerds and developers just like everybody else.

There is no reason to replace JACK with Pipewire if you want a pro-audio setup. The killer feature of PW would be video routing, but I have not seen any real world application doing that. Until then... don't believe the hype.

Post Reply