As the primary author of Ardour, I can point you at a dozen people who do this kind of recording with Ardour at least weekly. I can even point you (anonymously, alas) at a major UK-based mobile recording truck service that is now installing Ardour as its secondary recording systems, in scenarios that typically involve recording at least 72 tracks at once. Yeah, it would be nice if it was the primary system, but I'm patient. After all, its only been about 6 months since the last /. flamefest that declared that Ardour could not do , or ....

nobody agrees on (a) what the subsystem should do (b) what API it should have (c) how it should be enforced.

your description of your problems with JACK doesn't match any of the user experiences i've heard about for the last several years. perhaps you should be providing bug reports, feedback and other useful to the JACK development community rather than just commenting about it on /. ?

i wrote JACK (originally, and with help from many others) by the way.,

what do you consider "top end hardware interfaces"?

RME HDSP and MADI interfaces, the choice of most highly-multichannel configurations worldwide, work perfectly on Linux and have done for a long time. Perhaps you are one of those who believe that firewire devices are "high end"?

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.