Development halted until JACK gets its shit together

[Qix-]

Right now JACK is in shambles in terms of OS/X support.

---

The official build for JACK1 off homebrew fails with cryptic errors:

JACK compiled with POSIX SHM support.
loading driver ..
allocate_mach_serverport: can't check in mach port
2016-09-04 20:41:47.228 jackd[4396:17490] 20:41:47.227 WARNING:  140: This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent.h.
Error calling AudioUnitSetProperty - kAudioUnitProperty_StreamFormat kAudioUnitScope_Output
could not handle external client request
could not handle external client request
could not handle external client request

Further, the client sees a failed (NULL) pointer being returned but doesn't offer any insight within the status result.

The latest HEAD of JACK1 compiles and has similar results.

---

The official build for JACK2 doesn't install.

A user on a thread over at the JACK2 repositories seems to have built a newer version, but aside from it installing correctly, it doesn't actually work. Nothing connects, it almost seems to hang.

The JACK2 repository does not build at all for me, and from the looks of it requires several refactors of deprecated API usage to get it working.

---

So until either one of these projects works on OS/X Capitan, or a new implementation of JACK arises, this project is officially abandoned. Ping this thread when that happens and I'll finish Captain Jack.

I could definitely fix it but I'd have to maintain it as it seems the original developers have all but abandoned either project, and I definitely don't want to play customer support for JACK proper.

Sorry :/

[Qix-]

@joshdekock

[jdek]

@Qix- I worked for a while to get JACK2 to work on OSX well, but the changes were so drastic they wouldn't upstream it. JACK1 is definitely easier to work with in regards to code style.

I could definitely fix it but I'd have to maintain it as it seems the original developers have all but
abandoned either project, and I definitely don't want to play customer support for JACK proper.

I could too, I just haven't, as it wouldn't get upstreamed, as soon as my other commits get upstreamed, I will be fixing the rest of JACK1. I'd also be fine with maintaining JACK1, but the current maintainer doesn't want to transfer maintainership "just yet", it's been like this for what feels like a year now. It felt like kind of a miracle when the other commit fixing the global variable usage was merged, and I finally hoped that JACK1 would get started again.

If you subscribe to the mailing list here: http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org I will be sending an email this pinging the transfer of JACK1 maintainership, and if you could reply, that'd be great, to at least show that there are others interested in getting JACK1 rolling again.

[Qix-]

@joshdekock Totally agreed. I subscribed to the mailing list.

If you really want to maintain JACK, might as well get a head start by forking it and sprucing it up. I wouldn't mind jumping in and contributing either, if it meant things got rolling.

[cbarrett]

Just wanted to leave a comment that JACK1 builds under MacPorts. I'm just trying to find a "simple" way to capture Mac OS system audio, got here via the abandoned PulseAudioOSX project and then found the also abandoned JackOSX project, and now this.

[Qix-]

@cbarrett It's because of jackaudio/jack1#52. The new HAL plugins run under different users. Fix that and I'll finish CaptainJack :)

[Qix-]

@cbarrett Just re-read your comment. I currently (ab)use https://github.com/kyleneideck/BackgroundMusic since it's just a loopback interface with a nifty application on the frontend that's built for the HAL subsystem. If you're just wanting to record all system audio without anything JACK related, use that :)

[cbarrett]

@Qix- Thanks Josh! I saw that one—for me what I actually need is to send system audio over the (local) network. (I'm building a thin client workstation for myself.) Was looking at JACK or PulseAudio to do that. But I think I can probably just crib the sample code, and use it to write out linear PCM to a named pipe or a shmem or something.

[Qix-]

Yeah, probably best. You'll need a service running along with the HAL module. You can look at this source code though since the documentation on HAL plugins is a little lacking. TCP connections from a plugin are allowed, most other forms of IPC are not. Also, remember that you're not running your own process; a plugin is just a set of callbacks so you'll hang coreaudiod if you write any polling loops or anything like that.

Best approach is to get it out of coreaudiod first and then send it off wherever you need.

[keybounce]

I know that Jack2 works on 10.9.5. I saw comments about in the other thread about "Just set file permissions on the shared memory files", which is a complete fail when the problem is sandbox related (even with only one user involved, 10.9.5 requires a bunch of sandbox permissions AND bouncing coreaudiod after jackdmp has been started up).

I don't know what's needed for 10.10+ and the new audio system.

But just "capturing the system audio" isn't the goal, there's plenty of tools for that. Jack's key feature for me is sending audio from different programs to different soundflowers in an aggregate, so that they wind up on different audio tracks when recorded (permitting mixing separately).