Great summation!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.Is that library replacement hack to run jack applications directly on pipewire actually working well?
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.
I agree! Statistics: Posted by audiojunkie — Sat Aug 10, 2024 5:02 pm