Linux Users, What's You Distro Experience?

[glokraw]

The only mystery is why the person isn't also foregoing jack, and instead setting his software to use ALSA MMAP mode directly. The only explanation I can surmise is that his software doesn't support MMAP.

In any session, I may choose from a wide variety of software standalone instruments, effects and utilities, plugins in daws, and hardware devices, and qjackctl can connect their i/o easily. As far as I know, there is no such comprehensive connection/settings panel for alsa, and the one often mentioned for pipewire is far to tedious and inept (for me, at least)

For using a single daw and it's contained plugins, alsa may be fine, lots of Reaper users choose that.
Cheers

Some Hive 2 music in time for the weekend:



https://open.spotify.com/track/4365ibNB ... 310de64af0

[uOpt]

Is that library replacement hack to run jack applications directly on pipewire actually working well?

Seems like a tall order to get that flawless.

[uOpt]

Damn Linux nerds, keeping all the juicy bits to themselves...

https://www.youtube.com/playlist?list=P ... mGpF55yprD

Good video. Free of Voodoo.

[audiojunkie]

he dismissed pipewire and used jack (instead) is confusing

It's not confusing at all. Pipewire typically requires more buffering than Jack in order to avoid underruns (ie, audible bursts of noise). Pipewire wasn't designed with the lowest possible latency as a major goal. On the other hand, Jack was designed with that as a priority, (But note the fact that some of Jack's design choices, especially having hosts run in a different process than the audio play/record code, results in Jack being not as low latency as using ALSA MMAP mode directly).

Pipewire's primary goal is synchronization (particularly syncing audio to video). The first Pipewire version exhibitied so much more latency than Jack, that musicians complained, and the developers had to retool Pipewire to more closely resemble how jack does things. But in spite of that latter effort, they have not been able to deliver the same performance as jack (and frankly, I don't see any way they ever can. Pipewire is not a design that lends itself to low latency performance).

The only mystery is why the person isn't also foregoing jack, and instead setting his software to use ALSA MMAP mode directly. The only explanation I can surmise is that his software doesn't support MMAP. (There are a number of music apps that support Jack only. I advise linux musicians to avoid using such software).

The reason why distros are using Pipewire for the default audio engine is not because it offers the best performance. Rather, it's because pipewire replaces PulseAudio and jack both, and therefore supports the largest selection of apps that make sound (many of those apps not even tools for musicians, such as perhaps a game title). In other words. Pipewire is chosen for its ease of setting up a distro's sound for general use by all linux software.

Hehehe! I was the one that started and fought that war with Wim that brought about the change in pipewire. . For those interested, the whole situation is in a giant thread on the LinuxMusicians forum.

One thing I disagree with you about is Pipewire’s ability to achieve the low latencies that JACK on top of ALSA achieves—it can. Pipewire now uses the same IRQ based scheduling that JACK uses. Wim gave Pipewire a completely new second timing system especially for JACK, so that when using JACK compatible apps, Pipewire and JACK should achieve essentially the latencies with essentially the same buffering. To add to that, there are now gui controls for the most used configuration changes, and pipewire is now much easier to set up and use than JACK. There is no longer a need for a transport, like JACK uses—but, for flexibility’s sake, you can even use the same qjackctrl. Pipewire is the future of Linux audio.

An area I definitely agree with you on is with the way ALSA is accessed in Pipewire—they should have allowed (along with their current Alsa mode that talks to everything else), an Alsa mode that completely bypasses Pipewire and allows a direct tunnel to ALSA. Hopefully they will add that in a further update. Then there would be no need to disable pipewire to talk to alsa directly.

Also, remember that Pipewire is young. It is now at v1.2, but new things are getting added in almost every version. It gets better and better with time, and even the developers have declared JACK depreciated. How much more development can be reasonably expected there? Yes, things work now, but as time goes on the underlying libraries will eventually fall out of support. Pipewire is the way forward. We should embrace it and work with Wim to get the things that we need and want in it while Red Hat is continuing to fund it’s development.

[glokraw]

Also, remember that Pipewire is young. It is now at v1.2, but new things are getting added in almost every version. It gets better and better with time, and even the developers have declared JACK depreciated.

Not trying to be debbieDowner, but
1. Age, quality, and usefulness have nothing to do with version numbers.
2. I would hope there would be something new in EVERY new version. Bug fixes should not invoke version number changes.
3. Time passing does not guarantee 'better and better'. And personal/developer labels have no effect on code. Someone saying x, y, or z is deprecated means nothing to users happily relying on x, y, or z.

Videos/screenshots depicting successful pipewire integration of hardware instruments, daws, windows software in wine, and native linux audio software tools would be helpful, and might be a good new thread for you to start...no posts retained without including supporting pics and/or videos

Not to mention solid evidence of video/audio integration with the several linux NLE projects, working down from DaVinci Resolve on Fedora (and debian 12?), to those NLE's more readily cross-distro, and available via package managers...while still leaving the rest of the audio/video/comms/gaming/ infrastructure in working order

I really hope Wim has a team with broad coding experience, too big a project for one coder
Cheers

[BertKoor]

Not trying to be debbieDowner, but

ditto here...

1. Age, quality, and usefulness have nothing to do with version numbers.
2. I would hope there would be something new in EVERY new version. Bug fixes should not invoke version number changes.
3. Time passing does not guarantee 'better and better'. And personal/developer labels have no effect on code. Someone saying x, y, or z is deprecated means nothing to users happily relying on x, y, or z.

That is why we have Semantic Versioning as 1.2.3, so from the increment it can be judged whether it is:
1) a major update (can have breaking changes),
2) a minor update (improved functionality) or
3) merely bug fixes.

This is however just a thing to manage expectations, not a contract set in concrete.

So something v1.2 is indeed quite young. The future might be bright. Or not.

I've seen management issue statements such as "don't use software below v3: it has not matured yet". While avoiding bleeding edge is in general good, you'll miss some really good stuff.

As software matures (by further developments, after all software is "soft" because it can be changed) it often reaches a point where an attempt to change it costs too much effort. Keeping it in a 'soft' state has been proven to be very difficult. The architecture may be unfit for change, there can be technical debt, bit rot, too many cooks spoiling the soup, etc etc.

Then it is wise to declare it deprecated: take it as is, we're no longer maintaining it. Which as a consumer of it is a gamble. It is fit for purpose now, but in the future? In a system where anything depends on everything, it's a catastroph waiting to happen.

dependency-141873485.png

[FrettedSynth]

One of the REAPER camp here, agree with j_e_g direct to ALSA MMAP. Coming from Windows I am used to only one host connection and using plugins. Never had a desire to use the internet while in that room of my home. If I ever were to need the net I would setup a separate machine.

Choice is a good thing, so for others there is JACK and Pipewire.

[j_e_g]

Is that library replacement hack to run jack applications directly on pipewire actually working well?

Well, it doesn't support 100% of jack's features. (For example, I don't believe it supports Jack's "internal clients"). But the features it doesn't support are mostly esoteric functions not typically used by most software.

I have to say that Pipewire's "Jack and PulseAudio library replacements" approach, while occasionally buggy (for example, a program continuing to play audio several seconds after its window, and perhaps even its main process, has terminated -- this is undoubtably due to the amount of buffering used by Pipewire), does work much better than I predicted. I thought the Jack replacement was going to be a disaster. But my prediction was based upon the version of Jack that I reviewed prior to when JACK dev was taken over by some dev from Portugal (Fillippe I think his name is). Jack 2 did something rather "dangerous". Unlike Jack1, Jack 2 bypassed the library that ALSA provides for apps, and instead called directly into ALSA device drivers. Apparently, this Fillippe guy reverted all of that stuff back to the way Jack 1 did it -- using the ALSA official lib. And then, for reasons I can't explain, released this significant change as... Jack 2 again. So, unbeknowst to me, there actually are 3 major versions of Jack, but Fillippe didn't tag his version as distinctly different code from Jack 2 by bumping the version number. (He should have).

So there were actually 3 significantly different Jack code bases, and yet people never converged upon using only one -- ie, some people use Jack 1, some use Jack 2, and some are actually using a Jack 3 but they don't know that. And now with Pipewire, there is a Jack 4, although again, pipewire devs have failed to bump the version number to reflect that it's a significant departure from previous versions. That's undoubtably one of the problems with getting Jack working. Both developers of audio apps, as well as endusers, aren't really sure what Jack they're using/testing. And given the subtle differences in versions, it results in lots of subtle problems that take forever to deduce and fix.

So the bottom line is:

1) The state of Jack is a mess, due to lack of identifying the versions properly, as well as people failing to universally adopt one (because the versions weren't kept backward-compatible with features/performance. For example, Jack 2 failed to include some features of Jack 1, while introducing features that Jack1 lacked. So a person had to choose his Jack version based upon which one had the features/performance he needed).

2) Pipewire introduces a fourth version of Jack.

3) Jack 4, while not 100% compatible and occasionally buggy, works a lot better than I originally predicted it would (because I wasn't aware that there was actually a jack 3 upon which Pipewire was based).

4) Despite #3 (and audiojunkie's testimony otherwise), I still have found Pipewire's jack to require more buffering than other jack versions in order to avoid underruns. It's just not there (albeit close. After all, both do audio I/O in a different process than the host. And that is the big factor that contributes to underruns occurring).

5). Because of #4, ALSA MMAP direct wipes the floor with all versions of jack.

6) Because of #5, you'll want to do what Windows and Mac musicians have known for literally decades. You get the best performance and stability when you use a host that bypasses any "mixer software layer" (ie, Pipewire, PulseAudio, Jack) to go directly to the audio hardware drivers (ie, ASIO, WASAPI direct mode, ALSA MMAP), and then use effects/synths/samplers that are written as a plugin (versus standalone apps that have to be "connected" via some software "patchbay").

And that's thankfully all I have to say.

[Largos]

It never gets old seeing essay length posts about pipewire by people who have not even used it.

[uOpt]

Thank you for that information @j_e_g.

[audiojunkie]

Is that library replacement hack to run jack applications directly on pipewire actually working well?

Well, it doesn't support 100% of jack's features. (For example, I don't believe it supports Jack's "internal clients"). But the features it doesn't support are mostly esoteric functions not typically used by most software.

I have to say that Pipewire's "Jack and PulseAudio library replacements" approach, while occasionally buggy (for example, a program continuing to play audio several seconds after its window, and perhaps even its main process, has terminated -- this is undoubtably due to the amount of buffering used by Pipewire), does work much better than I predicted. I thought the Jack replacement was going to be a disaster. But my prediction was based upon the version of Jack that I reviewed prior to when JACK dev was taken over by some dev from Portugal (Fillippe I think his name is). Jack 2 did something rather "dangerous". Unlike Jack1, Jack 2 bypassed the library that ALSA provides for apps, and instead called directly into ALSA device drivers. Apparently, this Fillippe guy reverted all of that stuff back to the way Jack 1 did it -- using the ALSA official lib. And then, for reasons I can't explain, released this significant change as... Jack 2 again. So, unbeknowst to me, there actually are 3 major versions of Jack, but Fillippe didn't tag his version as distinctly different code from Jack 2 by bumping the version number. (He should have).

So there were actually 3 significantly different Jack code bases, and yet people never converged upon using only one -- ie, some people use Jack 1, some use Jack 2, and some are actually using a Jack 3 but they don't know that. And now with Pipewire, there is a Jack 4, although again, pipewire devs have failed to bump the version number to reflect that it's a significant departure from previous versions. That's undoubtably one of the problems with getting Jack working. Both developers of audio apps, as well as endusers, aren't really sure what Jack they're using/testing. And given the subtle differences in versions, it results in lots of subtle problems that take forever to deduce and fix.

So the bottom line is:

1) The state of Jack is a mess, due to lack of identifying the versions properly, as well as people failing to universally adopt one (because the versions weren't kept backward-compatible with features/performance. For example, Jack 2 failed to include some features of Jack 1, while introducing features that Jack1 lacked. So a person had to choose his Jack version based upon which one had the features/performance he needed).

2) Pipewire introduces a fourth version of Jack.

3) Jack 4, while not 100% compatible and occasionally buggy, works a lot better than I originally predicted it would (because I wasn't aware that there was actually a jack 3 upon which Pipewire was based).

4) Despite #3 (and audiojunkie's testimony otherwise), I still have found Pipewire's jack to require more buffering than other jack versions in order to avoid underruns. It's just not there (albeit close. After all, both do audio I/O in a different process than the host. And that is the big factor that contributes to underruns occurring).

5). Because of #4, ALSA MMAP direct wipes the floor with all versions of jack.

6) Because of #5, you'll want to do what Windows and Mac musicians have known for literally decades. You get the best performance and stability when you use a host that bypasses any "mixer software layer" (ie, Pipewire, PulseAudio, Jack) to go directly to the audio hardware drivers (ie, ASIO, WASAPI direct mode, ALSA MMAP), and then use effects/synths/samplers that are written as a plugin (versus standalone apps that have to be "connected" via some software "patchbay").

And that's thankfully all I have to say.

Great summation! I agree!

[audiojunkie]

Apparently, this Fillippe guy reverted all of that stuff back to the way Jack 1 did it -- using the ALSA official lib. And then, for reasons I can't explain, released this significant change as... Jack 2 again.

BTW, Fillippe (known as FalkTX here on KVRAudio) had stated in his blog his intention to end there being two versions of JACK, with the intention to call everything JACK 2 moving forward. That’s why he made the change (taking the best of JACk 1). So, the end result could have been JACK 3, but since he was the only remaining developer of the code bases, and the fact that JACK 2 was the only code base (getting developed going forward) was why he thought it sufficient for those who were following JACK to know that continued developments of JACK 2 was the JACK to use. I know. Clear as mud. But it explains his reason for not calling the result, JACK 3—JACK 2 was the last codebase still getting developed—no reason to change its name.

[j_e_g]

<duplicate message deleted>

[j_e_g]

FalkTX intention (was) to call everything JACK 2 moving forward.,,

Well, that was a mistake. FalkTX's version of Jack 2 is actually a combination of jack 1 _and_ jack 2 source code. It really isn't a continuation of either Jack 2 or Jack 1 specifically. It's effectively a Jack 3.

And Pipewire's version of jack is even more alien to those 3 codebases.It probably shouldn't even be referred to as a "Jack replacement". It's really just a translation layer.

[glokraw]

From a musicians end of the cable, all the esoteric details somewhat cloud the reality that, given a quality audio interface, the various releases of jackd work fine for normal small session recording situations. I can't speak (based on experience) to running a daw session with many dozens of effected tracks, using a modern cpu. With the current options offering adequate performance, the next criteria for making a choice, are ease of use, and the availability of desired gui's for displaying the software. I'll need to see proof of audibly and visually significant improvements, before spending more time testing. Still curious about anyon'e NLE experiences with pipewire.
Cheers