Installer fails to find installed JACK

I became a subscriber and downloaded the full version. The installer ran fine, but failed to find my installed JACK. It’s not a problem for me, because I always start JACK before running Ardour, but just FYI.

I would suggest submitting this as a bug (See Bug Tracker link at the top of this page), but also a bit more info would be needed, like what distribution you are using, how Jack was installed, where it was installed to, etc. Also a log of the install would probably be a good thing, as well as how did you run the installer itself?

 Seablade

… I always start JACK before running Ardour…

Ah, glad to hear that’s still supported. I think I remember reading it was the recommended method at some point, so I’ve been doing it that way for a long time, including with 3.5.403. But it hasn’t worked for me when I’ve tried the (free) nightlies – Ardour never sees the running JACK process. So sort of the opposite of gremlink’s problem. I wonder what’s different… I’m on Fedora 20 and 21 with CCRMA extensions (which comes with JACK2, FWIW).

Ardour nightlies comes with 3 backends (as will Ardour4). On Gnu/Linux these are ALSA, JACK and Dummy (the latter is only included with debug builds).

The first time you launch new Ardour it will ask (regardless if jack is already running). For subsequent starts, ardour will automatically use JACK if jackd is already running and the last used backend was JACK.

If this does not work as described, please file a bug-report at http://tracker.ardour.org/ launch Ardour in a terminal as

Ardour3 -D audioengine

and include the output.

PS.
The Dummy backend (no hardware i/o) is mainly useful for testing (it includes signal generators) and creating gdb-backtraces (it does not use realtime).

Direct ALSA (no jack) has one main advantage over jack: midi-latency compensation. Currently neither JACK1 nor JACK2 have options to set calibrate per port systemic midi-latency. Other than that it’s a tad more CPU efficient (less context switches).