Dummy check please. Is it true that:

• Jack can serve as audio loopback software between MacOS audio apps such as Pd
• Jack can run on an M2 processor
• The Qjackctl.app that is bundled with the Jack MacOS download runs on Monterrey without any additional runtime frameworks installed
• For Pd to send/receive from a Jack channel, Jack has to be running and you have to select Jack in the audio settings before you can select which particular Jack channel you want for input or output
• Soundflower is obsolete; Jack is current

?

Edit: I can confirm the 2nd through 4th bullet point but not the first and last. I've seen 2 tutorial videos on Mac audio loopback where you can see that the presenter has Soundflower installed in addition to whatever loopback software they were demonstrating, so that makes me scratch my head. RE that first point, I'm tentatively concluding that an audio app has to be Jack-aware (like Pd) in order for it to be routed by Jack, which isn't a requirement of other loopback drivers like Soundflower or Blackhole. Finally, it's worth noting that Jack doesn't come with an uninstaller, so to get rid of it you have to manually remove files from /usr/local and below, and the list of files can be found on one of the windows of the installation package if you scroll down. If that's not your cup of tea, don't install it!

TLDR: I'm not sure why anyone would want to use Jack on a Mac. Still happy to be schooled though.

@jameslo Maybe because people seem to have trouble getting it to work in Windows.... ...?
David.

@whale-av Could be, but it's also my impression that you can't do audio on Linux without it (Jack). C'mon y'all, school me.

@jameslo Linux can also use ALSA, OSS (not sure if any linux distros use OSS anymore but it is still in the kernel and many repos), and portaudio. Jack is the standard on linux since it makes routing audio easy. Some say Pipewire is going to replace Jack and PulseAudio but from what little I have looked into it I have seen no mention of low latency being one of its features. No idea on you Mac questions, been many years since I have used a Mac.

@oid said:

Some say Pipewire is going to replace Jack and PulseAudio but from what little I have looked into it I have seen no mention of low latency being one of its features.

That's fairly upfront though, https://pipewire.org/ --> "It provides a low-latency, graph-based processing engine on top of audio and video devices that can be used to support the use cases currently handled by both PulseAudio and JACK."

I haven't tried it yet though.

hjh

@ddw_music From what I can tell their definition of "low latency" means better than PulseAudio, when I looked into it not too long ago most people seem to get ~20ms which is not great. I would be thrilled if they succeed and give us something better than Pulse and Jack in a single package. but I don't think they are there yet. My distro has PipeWire installed by default but uses Pulse, looks to be a fairly simple process to switch and my jack install recently stopped working so maybe I will give it a try.

Are all these Linux audio routing frameworks essential to having audio output on Linux, or do they just augment Linux's built-in audio capabilities? Do audio apps have to be written to output to each framework specifically, or are they decoupled by a generic API?

(Sorry, as the OP I feel entitled to drag the level of this conversation down to my level of understanding )

@jameslo ALSA and OSS are low level/tied into the kernel. PipeWire, Jack and PulseAudio are more user level and communicate with ALSA or OSS. All of these have overlap but they are not quite the same thing. Essentially linux used OSS back in the day than OSS changed its licence so linux had to find something new in a hurry, enter ALSA which was not at all ready but pretty good, not as mature as OSS or as featureful but it did a good job within its limits, which is where Jack and Pulse come in. Jack and Pulse flesh out the features of ALSA but Pulse got adopted before it was ready and that first year or two was not fun and few seem to really like it, Jack is great when it works but can be a nightmare when it does not. Enter PipeWire which brings video into the mix and seems to solve many of the user/administration issues of the rest. Just fired up PipeWire for the first time ever and it seems to work quite well without issues but I have yet to give it a good test.

An application needs to be built with support for Jack, Pulse, ALSA and OSS if it wants to use them, PipeWire understands the languages of all of those and an app built with Jack or Pulse support will* work with PipeWire and unlike Pulse and Jack can also expose ALSA/OSS ports so applications can access them directly without the middle man which is one of the huge issues with Jack and Pulse, they both take over all available ports so no one else can get in. So now I am recompiling PD to see if it speaks to PipeWire through its Jack interface.

I know little to nothing about PortAudio, I believe it is a crossplatform library capable of talking to many different audio services.

*apparently you need to build the apps off of the PipeWire Jack libs and not the regular Jack libs which kind of sucks but nothing major, we don't have to wait for the devs to get around to fixing anything at least.

@oid said:

An application needs to be built with support for Jack...

So if that's true for Linux, then it seems likely that it's true for MacOS too.

@jameslo Yeah, an application needs to know how to talk to Jack if it is going to talk to Jack.

Forgot to mention, OSS is still the standard on the BSDs so it is not dead or anything. I think the build scripts may just detect the OSS emulation that is generally enabled in many linux kernels despite most brands of linux not having OSS installed. I think OSS on linux these days is primarily used by devs wanting to make sure things will work on BSD and probably a few niche areas but I do not really know.