[LAU] JACK clients at different period sizes

[Fons Adriaensen]

On Thu, Sep 15, 2011 at 12:48:39AM +0200, Dominic Sacré wrote:
> Hi,
> 
> I have a medium-sized Ardour session with a couple of plugins on most 
> tracks, in which I'd like to record some additional tracks. Due to the 
> number of tracks and plugins, it's not possible to run Ardour/JACK at 
> very low latencies.
> 
> The same machine (and the same sound cards) is also used for monitoring 
> for the whole band, using a huge instance of JackMix. This needs to be 
> run with as little latency as possible (128 frames per period, tops).
> 
> How can I solve this dilemma? Ardour's latency doesn't really matter to 
> me, as long as newly recorded regions are properly aligned with existing 
> material.
> 
> It might also be an option to run Ardour on a different machine via 
> netjack, but as far as I can see the period size of a netjack slave is 
> tied to that of the netjack master. It also seems doubtful that Ardour 
> would be able to do correct latency compensation in this scenario...
> 
> Any suggestions? Is there any way to run run a second, high-latency JACK 
> server piggy-back on a low-latency server?

If you can't decrease the period size, the the only option 
is do the monitoring *for the new tracks being recorded*
in hardware, using either a 'real' mixer or the one that
may be provided by your sound card. If you have RME gear
hdspmixer is the solution - this use case is why it exists.

If the number of new tracks being recorded simultanuously
is not too high you don't need a big mixer: one channel
for each 'live' input, and on or two for the mix of 
existing tracks that you make either in Ardour or using
a separate SW mixer. Doing punch-in/out will require
some attention, but otherwise things should just work.

The really hairy case is a new track created on the PC
using a soft synth or similar - this requires a short
period for acceptable monitoring. But with external
sources there shouln't be a problem.

The latest Ardour 2 should take care of latencies - see
Paul's post of today.

-- 
FA