Pipewire, Jack Applications & Low-Latency tuning for soundcards

[j_e_f_f_g]

<pipewire's> constantly changing buffersizes makes me believe that lowlatency was not the prime goal.

Wow. What a valid and effective point. I totally missed that one.

So I'm just gonna steal it, and pretend I said it.

Of course, someone will reply "We'll sprinkle conditionals all over the source code to bypass all these latency-constricting features. The net result will be you get the same thing as real jack."

And I'll reply "You wouldn't have to do any of that if you just didn't replace jack. In fact you'd be done already. You would have no need to implement soundcard interrupt driven" i/o. Because the only people who need that are the people already using jack and alsa to get it."

Then someone will reply "But jack needs to be replaced".

And I'll reiterate how for years, and years, and years I've been telling people "If you want to reduce your latency, try switching to alsa MMAP instead of jack." And nearly every four-legged creature on the planet earth has said. "Absolutely not. My latency is good with JACK. I'm perfectly happy with it. And if you want me to stop using it. you'll have to pry it out my cold, dead hands".

Does anyone think that a 100% backward compatible, "comparable" jack fork versus real jack is going to yield a bigger difference than alsa MMAP versus real jack? Why?

Then I''ll point out that what pipewire is offering by "bypassing all these latency-constricting features" is that now an enduser will need to run some utility and check a box labeled "Bypass bad stuff for music apps, but good for firefox". Then he can run Ardour with low latency. But whenever he switches back to other software like firefox, he has to go back to the utility and uncheck that box.

And this is an improvement over the existing, working thing you want to replace.... How?

disagreeing to make pipewire some kind of plugin for pulse:

Ewww. Who proposed that?

I'm advocating for a simple drop-in pulseaudio (only) replacement so if a user wants to replace pulseaudio with pipewire he does:

Code: Select all

apt-get purge pulseaudio
apt-get install pipewire

And done. Doesn't touch the guy's jack1, jack2, and/or alsa setup.

Is there anyone who doesn't think this is a good idea? Really? Really??

All things I want to do I can do with alsa and jack1.

We're in complete 100% agreement all the way down the line.

pip pip

Your cat is walking over your computer keyboard again.

[rncbc]

let me chime in this thread again ...

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

still standing, for most if not all scenarios, pipewire-jack is coping well with low-latency -- not crazy insane low-latency mind you, but a fairly good-enough one -- and given the end-of-year irq-scheduling prospect we'll have a serious contender...

the only thing that is prolly still not on par is jack-transport (and timebase) sync... it's still dang unreliable, specially on restarts and relocations atm. not big news but seriously a thing for me (and yours truly qtractor) -- don't trust it -- you've been advised!

cheers

[j_e_f_f_g]

for normal desktop alsa is enough.
For music I use jack.

I'm (in a sense) much where you are.

I use alsa for all my music apps. I use pulseaudio for everything else.

There's nothing about pulseaudio that isn't apropos for everything but audio content creation/production. It is being used by a vast quantity of linux user space code. In fact, now linux programs are much more likely to use pa versus any other audio api. If a linux app makes sound, it's probably through pa. I'm not sure why video guys are in dire need of an audio replacement. If the criteria is "does it play streaming video, like youtube, with sound ok?" (viewtopic.php?p=156451#p156451) then pulseaudio works fine.

If the big issue is that game developers aren't happy with what they've got on linux (viewtopic.php?p=157358#p157358), Valve already has your entire future planned out for you, and it probably involves Windows. You will be assimilated. Or as Klaus Schwab says "You will own nothing. And you will be happy". Just throw in the towel already.

But if the current crop of pulseaudio devs don't want to work on their own existing codebase anymore (viewtopic.php?p=157366#p157366), and they're ok with pipewire replacing it, I have no problems with pipewire replacing PA.

There's just 2 things I want to fight back over:

1) Pipewire replacing jack. I realize jack has been deemed "deprecated". Paul, Robin, Falk, and apparently everyone else who was working on it, have checked out of further work on it. That's fine. Jack is going to go away. Let it go. The linux audio support is finally moving in the way it should have done years ago. We're getting full-featured DAWs so a musician can finally say "at last, I can do everything I need to do with this one DAW that best fits my workflow. I no longer need to keep jumping around from app to app because none of them is strong enough on its own to do what I need. I can instead concentrate on improving my skills with my software of choice. And I've now got VST and Clap (and LV2) plugins to supercharge my DAW to be an all-inclusive in-the-box production environment. And I can set my DAW to directly i/o through ALSA, so no more session managers, nor separate audio control panels, nor searching through my root file system for some configuration file somewhere to adjust my latency/performance, nor starting/stopping/bridging add-on sound servers. I can do it all easily through my unified work environment".

And this is a very good thing. It means we're now past the "I'm working on a new audio server in my garage" phase, and on a trajectory for getting what Windows and Mac musicians have (and what so many linux musicians have previously acquiesed to WINE in order to obtain... like a drug addict who knows his heroin addiction is killing him, but it's the only thing that will dull his pain).

2) Third party apps that usurp the functionality of the OS. My first encounter with pipewire was when I updated Debian. I went to use some music app in conjunction with my midi keyboard controller. The music app was set to use direct alsa rawmidi i/o to the keyboard. For years, this has worked perfectly. In one day, pipewire ruined it. Pipewire grabbed my keyboard's MIDI i/o was hogging it. Was pipewire reading any MIDI input from it? No. The I/O LED on my keyboard was quiet. Was pipewire in the process of preparing to read MIDI input for a "client"? No, it was simply sitting there with its fat ass atop that MIDI port saying, "You alsa may be the officially elected entity in charge of this thing I'm sitting on. But there's a new vigilante in town, and I'm taking over".

There's a word that every other OS uses to describe such software. and that word is "trojan". You write this kind of third party software that takes from Windows OS exclusive control of hardware, and Microsoft will issue an advisory to every Virus Protection company of a newly discovered trojan pipeworm2023, and the next day every virus app will have wiped your software out of existence. Apple will do the same, plus kick you out of its app store. Google will toss you from its android app store too. Stop doing this!

[Impostor]

We're getting full-featured DAWs so a musician can finally say "at last, I can do everything I need to do with this one DAW that best fits my workflow.

Which DAW is that full-featured on Linux? My main DAW is MusE, because it fits my workflow best, but I can hardly claim I can do anything audio-related with it. For wave editing I still resort to Cool Edit for crying out loud! Also it does not support all linux native plugin formats. And for programming drums I still very much prefer Hydrogen.

[j_e_f_f_g]

Ardour is that foss alternative on linux.

If most of my musical parts were created by acoustic instruments (ie, playing an actual drumkit with microphones all over it, playing an acoustic guitar or acoustic piano, recording a choir, etc), then I'd likely agree with that.

But my musical parts are primarily software instruments controlled via MIDI. And for that, I'm firmly in the MUSE camp. In fact, I consider MUSE to currently be the best linux app. I do think that some things can be improved or revamped. But it's the first, and only, linux app that I would rather use than any alternate title on another OS.

Every now and then, I'll check out the latest version of some linux app that holds some promise. I'll do a quick test "project" to evaluate whether its usability has improved (from the previous time I tested it), and by how much. So far, none of them have gotten me to replace my windows software with those linux titles except for two choices -- Muse for music production, and geany for writing.

I've always been a big cakewalk fan, and I've used it for many years. But one day, I did my test on Muse, and I thought "This is better than Cakewalk". And right there, on that very day, it was goodbye calkwalk, and hello Muse.

I've currently got my eye on a linux wave editor (for creating my sfz instruments) called ocenaudio. (imposter, you should check this out. Cool Edit is a fine program, I used it long ago. But it's dated, and I consider ocenaudio to be better).\

[Impostor]

ocenaudio. (imposter, you should check this out.

Thanks. Looks like a viable CoolEdit replacement (eventually, I just can't let go). Much better user friendly impression than I got from Audacity, that's for sure.

[Impostor]

you gave not one hint why muse is betta and I bet, there aint one

MusE is da Bomb.

[alex stone]

for normal desktop alsa is enough.
For music I use jack.

I'm (in a sense) much where you are.

I use alsa for all my music apps. I use pulseaudio for everything else.

There's nothing about pulseaudio that isn't apropos for everything but audio content creation/production. It is being used by a vast quantity of linux user space code. In fact, now linux programs are much more likely to use pa versus any other audio api. If a linux app makes sound, it's probably through pa. I'm not sure why video guys are in dire need of an audio replacement. If the criteria is "does it play streaming video, like youtube, with sound ok?" (viewtopic.php?p=156451#p156451) then pulseaudio works fine.

If the big issue is that game developers aren't happy with what they've got on linux (viewtopic.php?p=157358#p157358), Valve already has your entire future planned out for you, and it probably involves Windows. You will be assimilated. Or as Klaus Schwab says "You will own nothing. And you will be happy". Just throw in the towel already.

But if the current crop of pulseaudio devs don't want to work on their own existing codebase anymore (viewtopic.php?p=157366#p157366), and they're ok with pipewire replacing it, I have no problems with pipewire replacing PA.

There's just 2 things I want to fight back over:

1) Pipewire replacing jack. I realize jack has been deemed "deprecated". Paul, Robin, Falk, and apparently everyone else who was working on it, have checked out of further work on it. That's fine. Jack is going to go away. Let it go. The linux audio support is finally moving in the way it should have done years ago. We're getting full-featured DAWs so a musician can finally say "at last, I can do everything I need to do with this one DAW that best fits my workflow. I no longer need to keep jumping around from app to app because none of them is strong enough on its own to do what I need. I can instead concentrate on improving my skills with my software of choice. And I've now got VST and Clap (and LV2) plugins to supercharge my DAW to be an all-inclusive in-the-box production environment. And I can set my DAW to directly i/o through ALSA, so no more session managers, nor separate audio control panels, nor searching through my root file system for some configuration file somewhere to adjust my latency/performance, nor starting/stopping/bridging add-on sound servers. I can do it all easily through my unified work environment".

And this is a very good thing. It means we're now past the "I'm working on a new audio server in my garage" phase, and on a trajectory for getting what Windows and Mac musicians have (and what so many linux musicians have previously acquiesed to WINE in order to obtain... like a drug addict who knows his heroin addiction is killing him, but it's the only thing that will dull his pain).

2) Third party apps that usurp the functionality of the OS. My first encounter with pipewire was when I updated Debian. I went to use some music app in conjunction with my midi keyboard controller. The music app was set to use direct alsa rawmidi i/o to the keyboard. For years, this has worked perfectly. In one day, pipewire ruined it. Pipewire grabbed my keyboard's MIDI i/o was hogging it. Was pipewire reading any MIDI input from it? No. The I/O LED on my keyboard was quiet. Was pipewire in the process of preparing to read MIDI input for a "client"? No, it was simply sitting there with its fat ass atop that MIDI port saying, "You alsa may be the officially elected entity in charge of this thing I'm sitting on. But there's a new vigilante in town, and I'm taking over".

There's a word that every other OS uses to describe such software. and that word is "trojan". You write this kind of third party software that takes from Windows OS exclusive control of hardware, and Microsoft will issue an advisory to every Virus Protection company of a newly discovered trojan pipeworm2023, and the next day every virus app will have wiped your software out of existence. Apple will do the same, plus kick you out of its app store. Google will toss you from its android app store too. Stop doing this!

Oh boy oh boy oh boy....

Jack is sample accurate.
Jack is sample accurate.
Jack is sample accurate.
Jack is sample accurate.
Jack is sample accurate.

When you have 20 audio tracks and maybe 10 midi tracks, and you're not pushing too hard, ALSA may do the trick.

When you have 400,600, or as i tested once some time ago, 800 tracks in Qtractor (Rui, you did good, Qtractor didn't roll over and die, like a bad actor) ALSA wobbled all over the place, and the timing was atrocious.

Switch to Jack, and voila, you can paint your little french girls with spot on sample accuracy.

Jack is sample accurate.

Nearly every discussion i've seen in here and other linux hellholes concerning the virtues or otherwise of alsa versus jack is based around musos using 10,20,maybe 40 tracks. It's almost as if there's an arbitrary limit on how many tracks we're allowed to have, and how much midi data we can pump through them in any given project. When the fine lads over at Linuxsampler were building the LS some years ago, I explained that 100 channels wasn't going to cut it with big orchestral projects. They increased the channel count to 999. I was so excited at this forward thinking attitude, I tested it with every same lib i have, running two LS servers with a total channel count of 1200 approx.

Jack is sample accurate.

Alsa does fine for the, and i say this respectfully, average user. Aging rock guitarists still reminiscing the good old days of LSD and seriously decent weed, synth goths, plasmic garage music builders, etc, will get on fine with Alsa.

Jack is sample accurate.

Any multi hundred track projects relying on really accurate timing, particularly midi, will find Jack's sample accuracy a path to Nirvana, with the eternal paradise of Valhalla just ahead.

Jack is sample accurate.

So please, no more assumptions on how these apps are used, in what is a purely subjective assumption of......"normal".

My two florins worth,

Alex.

p.s. Jack is sample accurate.

[GMaq]

Alsa does fine for the, and i say this respectfully, average user. Aging rock guitarists still reminiscing the good old days of LSD and seriously decent weed, synth goths, plasmic garage music builders, etc, will get on fine with Alsa.

Hey! I resemble some of those remarks!!

[alex stone]

blah blah lsd....blah blah....yaddah yadddah
please, people, ...BS is not cool....it s never been and it will never be

Yeah chill, it's a metaphor with a little humour added.

[alex stone]

Alsa does fine for the, and i say this respectfully, average user. Aging rock guitarists still reminiscing the good old days of LSD and seriously decent weed, synth goths, plasmic garage music builders, etc, will get on fine with Alsa.

Hey! I resemble some of those remarks!!

[j_e_f_f_g]

Jack is sample accurate.
ALSA wobbled

But alex, jack uses alsa to playback audio. So it can't be alsa that is causing the problem, otherwise it would also happen with jack.

It's got to be due to some difference higher up. I think QTractor uses different timing references for jack versus alsa. Or it could be due to a difference in buffering.

Have you tried Muse?

ALSA may do the trick.

Stop talking about raboof"s mom. Alsa is an upstanding woman.

And she's affordable too.

100 channels wasn't going to cut it
a total channel count of 1200 approx.

Your template is like the garden maze in the movie "The Shining". You could start scrolling through it, and by the time you get to the bottom, you'll have missed 2 presidential elections, and gone through puberty.

Anyway... ahem... NoBudget plugins.

[alex stone]

Jack is sample accurate.
ALSA wobbled

But alex, jack uses alsa to playback audio. So it can't be alsa that is causing the problem, otherwise it would also happen with jack.

It's got to be due to some difference higher up. I think QTractor uses different timing references for jack versus alsa. Or it could be due to a difference in buffering.

Have you tried Muse?

ALSA may do the trick.

Stop talking about raboof"s mom. Alsa is an upstanding woman.

And she's affordable too.

100 channels wasn't going to cut it
a total channel count of 1200 approx.

Your template is like the garden maze in the movie "The Shining". You could start scrolling through it, and by the time you get to the bottom, you'll have missed 2 presidential elections, and gone through puberty.

Anyway... ahem... NoBudget plugins.

Perhaps I could have been clearer. I'm referring to jack midi versus alsa midi.

Yes, I have muse installed.

As far as lots of tracks and navigating them goes, I get by, but Muse and Qtractor could both do with a folders feature, to make that navigation that much easier. Create a folder, add tracks to it, close/open the folder when you want to work on a track or tracks contained within)

[j_e_f_f_g]

jack midi versus alsa midi

Oh that's right. I remember now that you're using some giga libs, so you have a really complicated setup with Linuxsampler.

Are you running linuxsampler as a plugin inside of QTractor, or running it as a separate process connected via alsa sequencer API?

Because that could make a big difference in the resulting performance.

In other words, which of the follolwing methods do you use:

============================
I select QTractor's "Track -> Add Track..." menu command.
This pops up a dialog to enter the new track's properties. I select "MIDI" type of track. I check "Omni". Then I select the "Plugins" page, click the "Add..." button, and find/select the "Linuxsampler" LV2 plugin. I also check "latency compensation".
I click OK to dismiss the dialog and create my new track.

=============================
I run QSampler or Fantasia to start Linuxsampler.
I run QJackCtl, and click the "Connections" button.
I go to the "ALSA" page, and I connect QTrackor's MIDI Out to LinuxSampler's MIDI In.

==============================

You want to do #1, not #2,

Muse and Qtractor could both do with a folders feature

Muse has a group of 7 pushbuttons that allow you to set which types of tracks to show/hide. If you position the mouse cursor over the first button, a (yellow) tooltip will pop up that reads "Show midi tracks". If you click on this button, it will change to a dimmer color, and all the MIDI tracks will disappear from your window. They're still there, and they still play, but they're no longer shown in the window. If you click that button again, all the MIDI tracks reappear. You have 6 more buttons to show/hide other types of tracks. If you want to hide all of the plugins, click on the "Show synth tracks" button. (It's the rightmost button).

I'm pretty sure qtractor also has a way to hide/show tracks. But I don't know it offhand.

[j_e_f_f_g]

We don`t call it Bullshit anymore, we call it humour.

What do we call something that is both?

j_e_f_f_g's posts

See. I take better pot shots at me, than Largos and Merl combined. What the hell happened to today's brits??? They used to be so much funnier. Margaret Thatcher turned you folks completely somber.