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 »

GUI's look interesting but appear to be missing options (at least, the options I used) that eventually seemed to improve the pipewire experience for me. When or if those options are added it may become more useful.

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 »

asbak wrote: Wed Mar 29, 2023 8:28 pm

GUI's look interesting but appear to be missing options (at least, the options I used) that eventually seemed to improve the pipewire experience for me. When or if those options are added it may become more useful.

I agree with you as far as PWrate goes, but what is missing for you on the PIpeControl GUI?

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 »

Audiojunkie wrote: Wed Mar 29, 2023 10:41 pm

I agree with you as far as PWrate goes, but what is missing for you on the PIpeControl GUI?

The parameters are already detailed in my posts on this thread.

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 »

https://gitlab.freedesktop.org/pipewire ... ses/0.3.68

Code: Select all

The ALSA plugin has experimental support for IRQ based scheduling. This
should decrease latency for some (mostly USB) drivers. This should bring
latency within JACK latency. More work on this will be done before the
1.0 release later this year

The parameters are already detailed in my posts on this thread.

asbak would you be so kind to raise an issue at PIpeControl GUI github page?
I think you are the most qualified to explain to the developer what is needed to be done

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 there,

My qualifications aren't so great, I just messed with Pipewire until it "sort of" worked better than the defaults but there'd probably be better methods, settings and things I missed out on and don't understand. Still, with the changes I posted it did seem to work a little better for me. Those lua config files especially seemed to help get audio interfaces I tested working better because with the pipewire "out of the box" settings some of them were unusable.

What you mention is interesting about the alsa plugin improvements and also the library to run pipewire into jack, kind of like we pipe pulseaudio into jack.

revoxs wrote: Thu Apr 06, 2023 11:29 pm

https://gitlab.freedesktop.org/pipewire ... ses/0.3.68

Code: Select all

The ALSA plugin has experimental support for IRQ based scheduling. This
should decrease latency for some (mostly USB) drivers. This should bring
latency within JACK latency. More work on this will be done before the
1.0 release later this year

The parameters are already detailed in my posts on this thread.

asbak would you be so kind to raise an issue at PIpeControl GUI github page?
I think you are the most qualified to explain to the developer what is needed to be done

Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
wtay
Established Member
Posts: 21
Joined: Mon Apr 17, 2023 9:56 am
Been thanked: 23 times

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

Post by wtay »

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

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.

This is plainly wrong. The audio parts of PipeWire are exactly designed like JACK. It has a fixed buffer size audio processing in 1 format (float) with client side float mixing and clients waking up each other in turn. Instead of using shared memory (JACK) it uses memfd (to isolate memory from clients) and it uses eventfd instead of semaphores to wake up clients. Other than that, complexity and performance is identical (modulo latency, see below).

The simple API and format conversion you talk about is all client side and not part of the PipeWire server or even used when running JACK/Pro audio applications. The pulseaudio emulation is run on top of this and can easily be ported to run on top of JACK, if someone wants to do this.

The only reason why PipeWire does not deliver the same performance as JACK yet is because it doesn't have a solid IRQ based ALSA scheduling implementation yet (only timer based). As it turns out, some hardware does not deliver good latency when using timers, only when using interrupts. Work is happening to get IRQ based scheduling implemented in some next release.

So yes, this stuff is explicitly designed for low-latency comparable to JACK, your statement is wrong. If we can get there is another question but it's not a design limitation.

User avatar
rncbc
Established Member
Posts: 1060
Joined: Mon Apr 19, 2010 12:20 pm
Has thanked: 45 times
Been thanked: 256 times
Contact:

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

Post by rncbc »

also

when comparing to jack, and due to its reliance on soft-timers and not on hard-irqs, pipewire used to perform quite bad on preempt_rt patched kernels...

not anymore

as it seems, kernel 6.2-rt is performing here quite nicely nowadays--been noticing this ever since 6.2-rc1-rt1 (currently on -rc7-rt8) and pipewire(-jack) 0.3.67 and .68 (opensuse tumbleweed).

so, given @wtay's last note, I now strongly believe pipewire is converging to be on par to jack's and maybe someday, even exceed its legendary performance ;)

cheers

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 simple API and format conversion you talk about is all client side and not part of the PipeWire server

It doesn't matter whether you do this conversion in the server, or in client-linked code, It's the fact that it is being done at all. JACK does not allow clients to choose their own rate and depth. They must conform to the server settings.

Suggesting that, when using only jack apps, there's no conversion needed (because of the aforementioned jack limitation) is a bit disingenuous a reply to my point.

The only reason why PipeWire does not deliver the same performance as JACK yet is because it doesn't have a solid IRQ based ALSA scheduling implementation.

explicitly designed for low-latency comparable to JACK.

The fact that it was even designed to trigger buffer fills according to timer signals, rather than directly from alsa's signals, underscores that audio performance wasn't the top priority.

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

wtay
Established Member
Posts: 21
Joined: Mon Apr 17, 2023 9:56 am
Been thanked: 23 times

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

Post by wtay »

j_e_f_f_g wrote: Mon Apr 17, 2023 3:11 pm

It doesn't matter whether you do this conversion in the server, or in client-linked code, It's the fact that it is being done at all. JACK does not allow clients to choose their own rate and depth. They must conform to the server settings.

Uh? so you say that when a client, say mpv, wants to play an audio file with the JACK backend and the format of the file doesn't match the JACK server format and samplerate, this is not allowed? That's just crazy, of course something needs to convert in the end. In the PipeWire (and JACK) case, this is always the client that converts to the format of the server. Doing conversion in the server is a bad idea and not doing any conversion is just not possible.

You seem under the impression that PipeWire can take any format and samplerate and it will just convert it on the fly. That's not how PipeWire (or JACK) works...

j_e_f_f_g wrote: Mon Apr 17, 2023 3:11 pm

The fact that it was even designed to trigger buffer fills according to timer signals, rather than directly from alsa's signals, underscores that audio performance wasn't the top priority.

This is true, power consumption and dynamic latency compensation are more important for generic desktop usage and were an integral part of the design.

But the current design can support both timer based and IRQ based scheduling, the wakeup code just works on a different set of file descriptors and we just disable some of the dynamic options to make this work like JACK.

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 »

Does anybody know whether there is a way to use Pipewire as a client for Native Jack yet? One of the reasons for asking is that this could be useful to pipe consumer audio into Jack, instead of Pulseaudio as many are currently doing.

This way It would also make it possible to use FFADO drivers, which I don't think are currently supported by Pipewire? The FFADO drivers appear to allow the use of lower latencies than what is currently possible with ALSA drivers for firewire devices.

Some Focal / 20.04 audio packages and resources https://midistudio.groups.io/g/linuxaudio
tramp
Established Member
Posts: 2328
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 450 times

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

Post by tramp »

@wtay One thing I also get a report about is that it seems pipewire jack didn't gives unique names to the clients, which leads to issues when running multiple instances under pipewire. There is no issue when using jack directly.
https://www.reddit.com/r/Guitarix/comme ... tances_to/

On the road again.
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 »

@asbak

use Pipewire as a client for Native Jack

See here

There is also now

https://github.com/dimtpap/coppwr

Image

coppwr is a tool that provides low level control over the PipeWire multimedia server.
It aims to expose and provide as many ways to inspect and control the many aspects of the PipeWire multimedia server as possible. It can be used as a diagnostic tool for PipeWire and to help develop software that interacts with it....

Features:

  • Object inspection, creation & destruction
  • Process monitoring & profiler statistics
  • Metadata editing
  • Module loading

Developer provides flatpack, arch, deb, rpm...

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 »

Interesting, thank you revoxs =)

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 »

wtay wrote:

when a client wants to play an audio file with the JACK backend and the format of the file doesn't match the JACK server format and samplerate, this is not allowed?

Correct. A client must use a 32-bit non-interleaved float format for the data (jack_nframes_t), and the samplerate that the enduser has chosen. For example, if jack is set to 44100Hz rate, then the client can't provide 16 bit signed integer data at a sample rate of 48 KHz.

Why are you asking me the above? I know that you know the answer to your own question. Are you just testing me to see if I know it? Fair enough. It's a legitimate debate tactic. I answered it, so now you know I know too. Let's skip feeling each other out with rhetorical questions, and get to the real action.

wtay wrote:

the current design can support both timer based and IRQ based scheduling

I think you mean that it currently supports the former, but at some future date you intend to support the latter.

wtay wrote:

pipewire is explicitly designed for low-latency comparable to JACK

If it were explicitly designed for low-latency comparable to JACK, then that's what it would actually be delivering right now. The reason why it doesn't is because it wasn't designed to do what jack does -- fill buffers via an interupt from the audio hardware -- and instead was designed to do that via a timer interrupt, thus resulting in latency that is not actually "comparable to jack".

You can't say that pipewire was designed to do something it doesn't actually do.

But my issue with pipewire is more basic than that. You've said:

My masterplan was to replace pulseaudio and JACK

But for the life of me, I can't figure out why you thought it would be a good idea to replace jack at all. I dislike jack, and have been urging people to abandon it for years. And for that entire time, the vast, overwhelming majority of jack users have been insisting "JACK works perfectly for me. It does everything I need it to do, and I'm completely satisfied with it". Where the heck are you finding all these people who apparently want their working jack setup replaced with a clone still in devlopment?? Why would they want that?? Why would any of these "satisfied" jack users prefer that, instead of the less invasive solution of simply making pipewire a drop-in replacement for pulseaudio, and then implementing pulseaudio's "Request device" DBUS protocol so that pipewire can peacefully co-exist with jack just like pulseaudio does today? People have done a lot of work optimizing their systems for jack and puiseaudio, so why would they prefer to replace that setup with something that throws away the work they've already done, and introduces something else they now need to spend time optimizing,just to hopefully get back to what they had to begin with (since it's "100% compatible" and "comparable" to what they already have)? Why would they not want a solution that didn't come with all those issues I listed at viewtopic.php?p=157358#p157358 (and which you agreed were issues that concerned you, but which you admit that you currently have no ideas how to solve)? Why would they not want to continue using what they already are happy with? Why?? Do you have some reason other than ""because I can"? Seriously, I'd like to know, because it doesn't make any sense to me why/how you've concluded there needs to be yet another audio server that reinvents the wheel. We've already suffered too many of them, and given that all of them to date have been replaced by yet one more audio server, why have youj chosen to do it again?? Even Lennard Pottering, the guy who wrote "PulseAudio" told people to stop making new sound servers. Those of us who have been dealing with this insanity for years just want it to stop. Please someone stop it. Anyone.

I mean you haven't even finished emulating jack, much less actually gotten it to deliver comparable performance, and you're already trying to sell people on the idea that all that needs to be done is for pipewire to respond to interrupts from the audio card and you've got "comparable low-latency to jack". Without actually having tested that theory with a proof-of-concept model, how and why have you concluded that? And even if you achieve "comparable" results what advantage does "comparable" offer which isn't already served by what people already have and are happy with? Comparable here literally means "equal to" or "the same as". (And to be honest, I expect that pipewire will never deliver lower latency than jack because I think jack does what it does as efficiently as it's gonna get -- Paul even did speed tests with different IPC methods to choose the fastest implementation. I fail to see how you're going to best it without doing something that will break backward compatibility).

In conclusion, I think the decision to replace jack is not only unnecessary, it's a bad course of action. I would urge you to think some more about answers to the questions I've asked above (and issues raised, including in that post referenced above), because I would hope that the process of answering will result in you coming to the conclusion that there is indeed no need nor reason to replace jack. I hope you'll realize that my alternate suggestion of:

Make pipewire a drop-in replacement for pulseaudio, and then implement pulseaudio's "Request device" DBUS protocol so that pipewire can peacefully co-exist with jack.

... is a better approach.

If you want, I've got my own version of Pottering's DBUS protocol that has been fully commented, with some missing error checking added, a memory leak plugged, and rewritten/revamped to make it easily incorporated into a dynamic link library or a C++ class. I'd be delighted to send it to you, and provide any additional info/help you need, with the hope that you'll reverse course and do the above.

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

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 »

simply making PipeWire a drop-in replacement for PulseAudio, and then implementing PulseAudio's "Request device" DBUS protocol so that PipeWire can peacefully co-exist with jack

  • That's already possible, from what I have originally researched here .
  • As it was somewhat buried in the SPA Plugin System, nobody seemed to use it till now, although that would be a valid use-case for Pro Audio Folks;
  • On the gitlab issue, Wim answered the following 2 months ago:

    master now has jackdbus support. You can do

    Code: Select all

    pactl load-module module-jackdbus-detect

    and PipeWire will become a zero-latency JACK client when jackdbus is started (like with qjackctl).

    -> I guess that's a different approach and not the same code that I found in my research, but if this works as advertised - super nice.

If it were explicitly designed for low-latency comparable to JACK, then that's what it would actually be delivering right now.

yes...but it was not specially designed for low latency.

  • As I understood it, it was designed for it, but they chose not to use the IRQ-based approach from the beginning, which did not work out as expected for all use-cases;
  • But they made the architecture like so that they can plug in the IRQ-based approach - Which is to be expected to be implemented till end of year
Post Reply