Delta 1010LT - Flaky Monitoring via JACK

Installation & Configuration Linux
#1

Before I submit this as a bug, I’d like to see whether any of the gurus here have experienced this. I’m not sure this is an Ardour bug at all.

Interface: M-Audio Delta 1010LT. JACK configured for hardware monitoring. Ardour 3.1.0 configured for auto-input and record monitoring handled by JACK.

Mics connected to HW inputs 1 through 3. HW outputs 1 through 3 connected to inputs of an external console. All monitoring is done through this console.

Ardour: 3 mono audio tracks, with inputs connected to the first 3 HW inputs, and L outputs to the first 3 HW outputs.

When I arm the tracks for the first time, the 1010’s monitor routing changes as expected: each of the first 3 channels’ monitor sources switches from PCM to INPUT. Disarm the tracks, and the monitor sources switch back. I’m observing this via the Envy24 control app.

For a short amount of time, It works as expected when recording, rolling without armed tracks or with armed tracks and the session not REC-enabled, or when stopped, or during auto punch in/out, etc.

After an apparently random amount of time, and for no apparent reason, the hardware monitor switching simply stops working. Monitor signal routing will remain in its current state, and cannot be affected by track arming/disarming or REC-enabling/disabling/transport state. It can be changed via the Envy24 control app, and it appears to function normally from there.

I’ll do a few additional takes or punches, using the Envy24 control app to control monitoring manually, then as suddenly and mysteriously as it stopped, the auto-switching will start working again, but only for a few takes, at best.

Sometimes, restarting Ardour will remedy the situation temporarily. Sometimes it will not. Restarting jackd gives similarly random results.

No errors reported by either Ardour or jackd, nor any other hints as to a possible cause.

Any thoughts?

(I’d rather avoid handling the monitor routing manually, so please refrain from suggesting this. It’s nearly impossible to do this while punching multiple tracks.)

Thanks!

#2

JACK hardware monitoring is basically useless. I would advise you to construct a workflow that doesn’t require it.

The only thing it permits is to direct monitoring of input N on output N. This can be useful in some scenarios but typically is not what many users require.

If this is precisely what you need, then some difficult debugging awaits you or some sympathetic soul.

#3

Thanks, Paul.

Just so I’m clear on this, does the term, “basically useless” refer to its general usefulness in the field, or to the typical level of reliability one might expect from it?

OK, then, another question for anyone here. In your experience, what’s the maximum acceptable (or minimum perceivable) latency in software monitoring of a live track through headphones?

#4

Just a thought - maybe you’ve considered it - but what are you using for pre-amps? I use a console for input and monitoring - feed the mics into the console, take a feed from the inert points of the console into me 1010LT, and run the monitor output of ardour into a stereo input on the console. Use the console for the monitor mix (playback of already recorded channels plus the live channels that I’m recording), and I’ve never had any noticeable problems with latency. I don’t know whether a setup like that would be suitable in your application, but it works for me - I thought that was how everyone did it.

#5

@dennismtaylor: i was referring solely to the fact that JACK H/W monitoring is always input N -> output N. You cannot mix channels, reassign them, use a monitor mix etc. etc. etc.

#6

Thanks again, Paul. “input N -> output N” is exactly what I was going for, but with JACK handling the routing during punches. Nifty idea, but certainly not absolutely necessary.

@Matt: Yes, this is normally how I do it. I was just trying to be clever and make use of JACK’s ability to manipulate the routing on this particular interface. It would come in handy in punch-in/punch-out situations wherein the performer expects to hear the input only when it’s actually being recorded.

They’ll learn to live with it!

Or not. :wink:

#7

If anyone is interested, I’ve made a bit of progress on this. I’ll report it as a bug, but here’s what I found:

Whenever the playhead is positioned manually without rolling, then JACK ceases to control HW monitoring. This condition will resolve itself in some number of minutes, but it’s quicker to disconnect from JACK, restart jackd, and reconnect.

I won’t bother with details here, but this is 100% reproducible, and seems to be an Ardour 3 thing. Ardour 2 does not exhibit this behavior.

#8

stuff like this should be filed as a bug. i might reply to forum questions but i never, ever refer back to the forums for things that need work. i detest forums, actually :slight_smile:

#9

Bug filed. Thanks!