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

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

Post by asbak »

Hi Gmaq, no worries at all =)

AVLinux is the gold standard for a production grade audio production system so the reasoning behind why PW isn't suitable for it are totally valid.

My system is experimental, it's hardly production grade. Some of the audio packages on it aren't working 100% reliably for reasons that aren't totally clear. Could be coincidence, could be bugs in the applications, could be a particular soundcard, could be a particular soundcard settings.... things crash from time to time, it's still very much in the "getting things to work" phase.

But for those with a spare machine lying around or who want to gamble, for better or worse, those settings seem to be working for me to varying degrees, depending on the soundcard. Some seem to work better, some worse. Is it the card, is it the configuration.... who knows at this point.

With one card it seemed to work really really well to the point that it wasn't even necessary to set the CPUfreq to performance. Will this be repeatable, will this behaviour remain consistent, again, who knows.

On some of the other cards I wasn't so lucky and had to switch it to "Performance" to avoid xrunning. Perhaps the secret sauce parameters for the other cards aren't quite right yet, who knows.

Will I be able to do a repeat build and achieve similar results on an identical laptop? Theoretically yes but who knows. :mrgreen:

But yeah, for those who are interested and who have similar hardware and OS, those Pipewire tweaks are easy to implement and roll-back later if required without complications so if a user's current latency with PW is sub-optimal it's worth trying. Hopefully others have additional tweaks, tips and tricks. (My real reason for making this thread.) :mrgreen:

Obviously the usual audio optimisations still need to be implemented as well, the tweaks in this thread only cover a small part of Pipewire.

All the best

GMaq wrote: Sat Mar 18, 2023 4:26 pm

@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..

Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
User avatar
Audiojunkie
Established Member
Posts: 384
Joined: Thu Feb 21, 2019 4:27 pm
Has thanked: 379 times
Been thanked: 147 times

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

Post by Audiojunkie »

j_e_f_f_g wrote: Sat Mar 18, 2023 6:48 am
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.

We’ll simply have to agree that we disagree on this subject. Pipewire is meant to be the grand unifier for multimedia on Linux—next generation technology, if you will. Configured correctly, there should be little difference in latencies between the Pipewire server and the JACK server. The one glaring omission that I see, is that pipewire does not yet have an easy to use GUI-based configuration panel. Everything still has to be configured manually. Once a GUI-based configuration package gets built, Pipewire will be as easy as Windows or Mac. Remember, Pipewire is still relatively new. Each and every update brings lots of useful features and improvements—just look at the latest release that came out a few days ago as an example of the constant influx of features and improvements. Pipewire is the future, and the future is bright. I’m very optimistic about it and the continual progress that is being made.

User avatar
Audiojunkie
Established Member
Posts: 384
Joined: Thu Feb 21, 2019 4:27 pm
Has thanked: 379 times
Been thanked: 147 times

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

Post by Audiojunkie »

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... 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..

Maybe visit the project again with Debian 13. Debian is my second favorite distro. I like so many aspects and philosophies that make up the Debian vision. In fact, I plan on migrating my desktop system to Debian soon. However, For my laptop, I choose Fedora. I know you know and understand my reasoning, but for others (if there are any) that don’t, let me explain:

There are bleeding edge rolling distros, and there are conservative versioned distros. Arch is bleeding edge, and Debian is a conservative distro. The software released with official Debian releases runs roughly 2 years behind each other, with the exception of jumps in progress with every Debian versioned (point) release. With little exception, the Debian family of distros will always be running behind the Arch distros. To me, the constant maintenance and upkeep required by the Arch family of distros takes up too much of my time—especially when dealing with manual interventions. The happy medium ground for me is Fedora, which tries to stay on the leading edge, if not bleeding edge of new technologies, with very little maintenance, and almost no manual interventions. Fedora is also the primary contributor to pipewire. It is natural to expect that Pipewire will perform the best with Fedora at first, and later on, as other distros adopt pipewire and learn the configurations and advances from the pipewire project, they too will adopt the best configurations and techniques. Maybe, given sufficient time, you’ll begin to change your mind as Debian gets optimized for Pipewire usage.

User avatar
Audiojunkie
Established Member
Posts: 384
Joined: Thu Feb 21, 2019 4:27 pm
Has thanked: 379 times
Been thanked: 147 times

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

Post by Audiojunkie »

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.

That is not how I understand it. While true that running ALSA with no server running on top will be more efficient, and potentially faster than ALSA through Pipewire, running JACK through the JACK server and running JACK through the Pipewire server should yield very similar results. And, as a bonus, due to the all in one design of Pipewire, the latency of running PulseAudio apps through Pipewire, as opposed to the PulseAudio server, should be greatly reduced. Sine we last spoke on the subject, have you set up and used the Pipewire server?

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 »

Audiojunkie wrote:

JACK through the JACK server
JACK through the Pipewire server
should yield very similar results

A racecar should get you from one location to another. A horse and buggy should give you the same result (as long as it doesn't matter to you how long the trip takes).

But they are not the same, and in fact, are different entities. Pipewire is an entirely different codebase than JACK. And it has a different use case. I wouldn't assume that the two will give you the same results. I've already encountered differences in the way Jack, PulseAudio, and Pipewire behave, for example, in their allocation of devices. I had to remove Pipewire from my system in order to get sound working in programs that have no trouble accessing the hardware when PulseAudio or Jack are installed. That they don't exhibit the same behavior doesn't surprise me, as they are all independent code bases. That's typical given this scenario.

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

User avatar
Audiojunkie
Established Member
Posts: 384
Joined: Thu Feb 21, 2019 4:27 pm
Has thanked: 379 times
Been thanked: 147 times

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

Post by Audiojunkie »

j_e_f_f_g wrote: Sat Mar 18, 2023 3:59 pm
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.

It’s interesting, where are you getting your information? Because what you are saying is most definitely not what the Wim Taymans says. In fact, it has been stated over and over again that equivalent low audio latency was an intentional and essential part of the design of pipewire. In fact, what you are saying doesn’t even make sense. Who would intentionally design a unified Linux audio server that is meant to seamlessly provide ALSA, PulseAudio, and JACK functionality, when a key design point behind JACK is the low latency. It wouldn’t make any sense if the unified server didn’t try to offer the the same functionality, as closely as possible.

You are correct however, when you state that Pipewire isn’t a “JACK3”. It was meant to seamlessly provide a unified and compatible functionality of the existing PulseAudio and JACK servers, while still also allowing access to ALSA functionality as well—no need to deal with simultaneous pulseaudio or jack server conflicts. Also, you are correct that it isn’t an ALSA2. ALSA is still ALSA, and Pipewire runs on top of ALSA, just like the PulseAudio and JACK servers would. But to suggest that Pipewire is akin to being a PulseAudio2 doesn’t quite cut it in my opinion, since Pipewire is meant to be a replacement for PulseAudio and JACK. I think the best definition of Pipewire is what has always been stated by its design goals—simply, a unified PulseAudio/JACK server.

I believe that Pipewire will eventually allow Linux to run low latency audio as simply and as easily as Windows and Macs do now. A GUI-based configuration tool is really all that is lacking to make this a reality. Currently, all the functionality is there right now to do this through the command prompt, and configuration files. Once a GUI-based front end tool gets written to allow you to easily and graphically configure Pipewire, I truly believe there will be no more opposition to the switch away from separate PulseAudio and JACK servers. Pipewire truly is the future. You just need to catch the vision and the possibilities. :)

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 »

Audiojunkie wrote:

Pipewire is meant to be the grand unifier for multimedia on Linux

Right. It's the "lowest common denominator" in audio support. It's generic, simple, attempts to emulate everything that came before it, and is targeted as a "multimedia API" for your typical desktop/GUI app. I expect that it will soon be used by most linux apps.

But this is exactly what you don't want if you're looking for low latency. You don't want a generic multimedia API with lots of emulations baked into it. And you don't care how complex your "pro audio API" is, because performance is top priority, and ease-of-use is readily sacrificed for that goal.

Pipewire is like Microsoft's DirectSound (the audio portion of DirectX). It's meant to be a generic multi-media API for general use (although it's not designed like DirectSound). ALSA's MMAP and JACK are like ASIO, or WASAPI exclusive mode. It goes around the WIndows audio API in order to get improved performance. It's designed for pro audio use, and is intended strictly for audio apps.

once pipewire has GUI configuration tools, it will be as easy as Windows or Mac.

No doubt. But like DirectX on an XBox, or CoreAudio on an iPad, it will always be a generic multimedia API that can't achieve the same efficiency as a specialized audio API. It's not designed for that (although I understand why people are thinking that it can. One would assume that Pipewire wouldn't emulate Jack if it couldn't reproduce its performance. But when it comes to linux devs, this is a bad assumption. The history of linux app development is littered with examples of devs doing things pretty much just for the hell of it, and severely disappointing people who discover that the "next big thing sure to be everything to everyone" doesn't in practice do what people were misled/hyped to believe it would do. How many times are people doing to fall for this? We've had dozens of OSS audio servers that people told me were going to make everything previous obsolete. And every one of them ends up ultimately no better, at best, and another source of problems at worst).

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

User avatar
Audiojunkie
Established Member
Posts: 384
Joined: Thu Feb 21, 2019 4:27 pm
Has thanked: 379 times
Been thanked: 147 times

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

Post by Audiojunkie »

j_e_f_f_g wrote: Sat Mar 18, 2023 9:54 pm
Audiojunkie wrote:

JACK through the JACK server
JACK through the Pipewire server
should yield very similar results

A racecar should get you from one location to another. A horse and buggy should give you the same result (as long as it doesn't matter to you how long the trip takes).

But they are not the same, and in fact, are different entities. Pipewire is an entirely different codebase than JACK. And it has a different use case. I wouldn't assume that the two will give you the same results. I've already encountered differences in the way Jack, PulseAudio, and Pipewire behave, for example, in their allocation of devices. I had to remove Pipewire from my system in order to get sound working in programs that have no trouble accessing the hardware when PulseAudio or Jack are installed. That they don't exhibit the same behavior doesn't surprise me, as they are all independent code bases. That's typical given this scenario.

There are several of us that are getting results equivalent to the JACK server latencies. That’s hardly a horse and buggy comparison. The goal is to have a one to one experience with Pipewire, compared to JACK. The Pipewire developers encourage reports of incompatibilities and differences in behavior. It is their stated goal to eliminate those issues. With every release, there are fewer of these issues. Maybe I missed it, but I don’t recall seeing any issue posts or communication on the Pipewire site regarding your experiences or issues. Did you post any? Why not help the project resolve your issues by reporting them and testing to confirm issue resolution? I think everyone would benefit from your contributions. :)

User avatar
Audiojunkie
Established Member
Posts: 384
Joined: Thu Feb 21, 2019 4:27 pm
Has thanked: 379 times
Been thanked: 147 times

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

Post by Audiojunkie »

j_e_f_f_g wrote: Sat Mar 18, 2023 10:31 pm
Audiojunkie wrote:

Pipewire is meant to be the grand unifier for multimedia on Linux

Right. It's the "lowest common denominator" in audio support. It's generic, simple, attempts to emulate everything that came before it, and is targeted as a "multimedia API" for your typical desktop/GUI app. I expect that it will soon be used by most linux apps.

But this is exactly what you don't want if you're looking for low latency. You don't want a generic multimedia API with lots of emulations baked into it. And you don't care how complex your "pro audio API" is, because performance is top priority, and ease-of-use is readily sacrificed for that goal.

Pipewire is like Microsoft's DirectSound (the audio portion of DirectX). It's meant to be a generic multi-media API for general use (although it's not designed like DirectSound). ALSA's MMAP and JACK are like ASIO, or WASAPI exclusive mode. It goes around the WIndows audio API in order to get improved performance. It's designed for pro audio use, and is intended strictly for audio apps.

once pipewire has GUI configuration tools, it will be as easy as Windows or Mac.

No doubt. But like DirectX on an XBox, or CoreAudio on an iPad, it will always be a generic multimedia API that can't achieve the same efficiency as a specialized audio API. It's not designed for that (although I understand why people are thinking that it can. One would assume that Pipewire wouldn't emulate Jack if it couldn't reproduce its performance. But when it comes to linux devs, this is a bad assumption. The history of linux app development is littered with examples of devs doing things pretty much just for the hell of it, and severely disappointing people who discover that the "next big thing sure to be everything to everyone" doesn't in practice do what people were misled/hyped to believe it would do. How many times are people doing to fall for this? We've had dozens of OSS audio servers that people told me were going to make everything previous obsolete. And every one of them ends up ultimately no better, at best, and another source of problems at worst).

Again, I will have to respectfully disagree with you. Saying that everyone is experiencing the equivalent of a Windows Directsound experience on Pipewire is disingenuous. Many of us are already experiencing latencies equivalent to what we experienced with the JACK server. With each passing version of Pipewire, I expect the number of users experiencing similar good results to increase, rather than decrease.

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 »

My 2c so far on real-world testing:

  • Latencies in pipewire with a selection of tested soundcards are low enough for me to not notice, or so marginal that they are almost imperceptible. However, I'm not a Steely Dan grade session player so mileage for others may vary, perhaps there will be enough of a gap for them to pass the blind-fold test and successfully identify switched instances between JACK + ALSA and Pipewire. For all intents and purposes, I don't think that I could pass such a test with my newly set up laptop.

  • The choice & configuration & drivers of the soundcard does appear to make a difference, in some cases a significant one. I realize that I'm stating the (duh!) obvious here, but it's worth reiterating. Even fancy high-end stuff that probably works well or fast on Windows / Mac may not perform so well under Linux conditions where the drivers may be suboptimal. I'm not claiming that audio performance under Linux is and will necessarily be suboptimal but just pointing out that the regular suspect audio interface manufacturers cater for the Windows & Mac markets and don't care much about Linux audio. How well a given device will work can be a matter of luck, how charitably the manufacturer provided information to sound driver devs, how inspired the devs were feeling, alignment of the stars etc.

  • With most tested cards I had to enable CPUfreq performance mode to avoid xruns. What do I mean by this. What I mean by this is that my standard test is to push a demanding workload through the audio system to see when / how / where it falls over and starts xrunning.

The Internut is littered with claims by experts (yes I'm exaggerating, but not by much) about how great their 20 y/o audio interfaces run at 16/2/48kHz but what proof have any of them ever provided about how well this will work with any kind of significant workload and demanding plugins? They NEVER provide any such evidence or convincing arguments, and you know you are dealing with a timewaster.

Yes sure, under light load conditions it may well "work" and not xrun for a while. For myself, without setting performance mode, sooner or later the system will xrun.

Again, here the choice of soundcard appears to make a difference. Some perform significantly better under load and without performance mode set, running under Pipewire (possibly also under JACK + ALSA but not tested), than others. Your "luck" here does indeed seem to depend on your choice of hardware.

  • For MY PERSONAL CIRCUMSTANCES, I feel that thus far, my Pipewire experiences this time around (previous attempts did not go well for MY PERSONAL CIRCUMSTANCES), is positive.

FOR ME, I feel that Pipewire can substitute for JACK + ALSA (+ Pulse routed via JACK).

  • I also retain the option of easily switching between ALSA + Pulse & Pipewire with a few commands which can be scripted. JACK + ALSA is there if I need it, installed and ready to go. It can happily co-exist with Pipewire. People who go around telling you that "you shouldn't have jack installed if you are using pipewire" possibly did not investigate these matters for themselves.

  • Consumer audio applications (Bluetooth Headphones, Zoom calls, MS Teams Calls, Youtube videos and more) should now work fairly easily & seamlessly in Pipewire. No more switching around depending on what I need to do.

  • Jack applications can be started directly from the menu or command line without setting environment variables, using long-winded switches to send some or other value to the application when starting and more. Perhaps there are cases when this is still needed, I can't say for sure. On my system I don't think it's necessary any longer since the jack.conf configuration file changes should (I hope???!!!) now hopefully be handling this.

According to htop my audio processes are running with a 95 priority so hopefully things are already good there.

  • For myself, it feels like audio management is now simplified (after set up was completed) to the point that I can just click & go and not have to fuss with workarounds, of which there would usually be no way to remember the syntax, which again required to having to look it up again.

YOUR MILEAGE MAY VARY. PERHAPS PIPEWIRE ISN´T FOR YOU. I CAN ONLY RELATE HOW THIS EXPERIMENT APPEARS TO HAVE TURNED OUT FOR MYSELF.

If any readers have additional configuration & tuning tips to contribute which may assist in further improvements, PLEASE ADD THEM BELOW.

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 »

For what it's worth, here is an upstream repo for Pipewire which may or may not have more recent & useful packages than the standard repos. I didn't use this myself (used different methods) for my build but if I were to start all over again this option may be worth considering.

https://launchpad.net/~pipewire-debian/ ... e-upstream

Code: Select all

sudo add-apt-repository ppa:pipewire-debian/pipewire-upstream
sudo apt update
Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
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 »

It's all fine and I am not trying to get anyone to use this system or that.
But I want just to correct one piece of wording:
ALSA is always there. It is the driver. Pipewire does not replace ALSA. If you write JACK+ALSA you need to write Pipewire+ALSA. Otherwise it's just JACK or Pipewire.

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 »

Yes yes you're right, I wasn't trying to suggest that Pipewire replaces ALSA but to some readers the unfortunate choice of wording may appear as such.

Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
revoxs
Established Member
Posts: 20
Joined: Sun Dec 04, 2022 11:35 am
Been thanked: 19 times

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

Post by revoxs »

re: Pipewire GUI's:

https://github.com/pkunk/pwrate
Image

https://github.com/portaloffreedom/pipecontrol
Image
Image

For Debian based systems, there is also a script to switch between PipeWire and PulseAudio:
https://github.com/jtsagata/audio_switch

User avatar
Audiojunkie
Established Member
Posts: 384
Joined: Thu Feb 21, 2019 4:27 pm
Has thanked: 379 times
Been thanked: 147 times

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

Post by Audiojunkie »

Oh! Wow!! Very cool!! Thanks for posting this!!! Pipecontol loojs like it will make things even easier!! 😎👍🏼

If this works for me, I’ll only need to do the following for easy low latency on linux:

  • Set realtime priorities and memlock for my audio group (and add myself to the group
  • Set my kernel boot parameters in Grub ( Threadirqs and peeempt=full
  • Run pipecontrol to set my Pipewire defaults

Things just keep getting better and easier! 😎👍🏼

Post Reply