(General Questions) Hardware Monitoring on Linux

(Hardware) Monitoring is the reason that keeps me going back to Ardour on Windows for recording (at least bigger sessions), while for mixing and post-production I am really really happy on Linux only.

I use RME soundcards (lately Fireface UFX II) for many many years now and of course, on Windows the driver’s own routing/monitoring capabilities are fantastic. The interface works very well in “class-complient” mode on Linux too and yes, you can create hardware mixes (e.g. for zero-latency monitoring) on the interface itself; but the comfort of doing it via the DAW is just no comparison…

On https://manual.ardour.org/recording/monitoring/monitor-signal-flow/ it is stated: “hardware monitoring […], on some cards this function can be controlled by Ardour. This is a nice arrangement, if the sound card supports it, as it combines the convenience of having the monitoring controlled by Ardour with the low latency operation of doing it externally.”

@paul: Five years ago you wrote in another thread:

So I guess my questions are (especially looking forward to the new foldback-functions in Ardour6!!):

  1. (On Linux:) Am I understanding correctly that this is only possible (if at all) when using JACK, not ALSA (that you generally recommend)? (So far I used ALSA more or less exclusively.)
  2. Did something change in the last five years, or is it still the better option (of course the best remains hardware monitoring configured on the hardware itself) to keep buffer/latency low, trust latency compensation and use software monitoring?
  3. Will Ardour6 use ASIO-direct-monitoring for the foldbacks on Windows?

Thanks a lot!

In reverse order:

  1. No
  2. Depends on your workflow.
  3. JACK provides a mechanism to enable direct 1:1 hardware monitoring on old RME hardware. This turns out to be extremely limited in its usefulness, and so was never extended. Most other hardware that supports h/w monitoring doesn’t even expose the sort of “on/off” switch that RME did, presumably because it is of so little utility most of the time (typically you want the monitored signal going somewhere other than the channel(s) it arrives on).

You can still do h/w monitoring on (almost) any card that supports it, but not by using capabilities that are part of JACK or Ardour - just use an appropriate control application for the device in question. This allows much more flexible and useful configuration than the simplistic 1:1 model JACK, and the early RME’s and ASIO’s design implies. It doesn’t require any particular audio backend, since it uses a “side channel” mechanism for controlling the device. Alas, the availability of such applications tends to be limited on Linux.

For me, the “gold standard” for this sort of thing is embodied by the contemporary MOTU devices, which have a grid/patchbay that can be controlled from a web browser to create (almost) arbitrarily hardware monitoring designs. They can be manipulated from any device (with a browser), and at any time. This is so far ahead of the RME/ASIO design that it’s not funny.

The design of foldback busses specifically embodies the “more complex” routing I’ve referenced above, and thus ASIO direct monitoring, or early RME style monitoring, is not useful in that context.

Thank you very much for this detailed answer! Of course - as you wrote - in any useful monitoring situation it has to be possible to mix and route the input signals arbitrarily (as opposed to “1:1”).

If only I had one (on Linux too) from/for RME… :smirk:

If I understand you correctly, the new Ardour6 foldback busses do always (on Linux and Windows) have to be “software monitoring” then. [Maybe I use “ASIO direct monitoring” in a wrong way, but on Windows it was possible to have a DAW control the RME internal mixer not only in 1:1, but “with routing” of signals… But anyhow, that’s gonna be a great feature (for me, at least on Linux)!!]

Surely you are right about the utmost ingenious web browser controlling capabilities by MOTU… But there might be some advancement on the RME side too: A Linux kernel patch to access the RME Babyface Pro’s internal functions was just submitted to ALSA… This could be a start, maybe more RME interfaces will follow…

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.