Nobody who is serious about audio production attempts to sync two audio interfaces without an explicit sample clock (aka "word clock") sync connection. Whether this is done implicitly, as is possible with firewire based interfaces, or via an additional coax cable with suitable termination on a PCI card doesn't matter: you don't get sync out of two separate clocks without resampling, which is the enemy. You can even take out your soldering iron if you want and run a wire between two el-cheapo consumer interfaces. Not recommended for beginners.

People commenting on technical matters that they know less about than they make it sound: $0.02
People commenting on technical matters and honestly reflecting their knowledge level: $10.00
People who actually understand this stuff: priceless.

1) JACK was not conceived as a plugin system. It is there to connect processes. The cost of context switches is too great for this design to scale to a level that can replace an in-process plugin API.

2) because of this, JACK will rarely be handling audio data flow that is "complex" - that kind of thing happens inside of applications, and rarely between them.

3) JACK2 (aka jack 1.9.X or jackdmp) has support for parallel data flows

4) It is not true to say that user space cannot be hard real time in a practical sense. If you approach the absolute definition of hard real time, then almost nothing on Linux, even with an RT-patched kernel, is hard real time. In the sense of providing sufficient timing guarantees to meet the hardware limits of current (and imagined) audio interfaces, the RT-patched kernel makes it possble for user-space code to be sufficiently hard-RT that the difference between these two definitions doesn't matter.

5) Linux is already used by "hardcore professionals". There are at least 3 manufacturers of large scale mixing consoles in which the DSP signal flow is being handled by Linux on more or less off the shelf components. Their users, of course, don't see Linux at all.

The "pre-emptive" kernel is not the one recommended for low latency configuration. The pre-emptive option merely improves performance, but does not provide any realtime-ish scheduling guarantees. For that you need an RT-patched kernel. This is NOT necessary for many latency settings.

Furthermore the current JACK ALSA MIDI backend is known to have notable timing bugs, and it is much better to use the current version of a2jmidid. In the coming weeks/month, I will be merging that into the standard JACK ALSA MIDI backend.

No distribution has taken JACK seriously in the sense of providing developers or other developers to help improve it. More money to work on JACK has come from Solaris users than anyone based on Linux.

Mr. Ardour/JACK.