Topic: Compensating for round trip latency in a mixed I/O environment.
OK.
So not to beat a dead horse here, I've seen this issue addressed elsewhere in the forum, e.g. here.
The problem is the improperly corrected for round trip latency (RTL) at digital I/O when using such I/O in a setting where the audio driver's master offset value is set and used for correcting for RTL at analog I/O accurately.
Typically this happens with all cards that have mixed I/O and are not exclusively digital. So the UFX is a perfect example. 12 channels of analog I/O that are spotlessly compensated for and then 8 ADAT channels at 2496 that come in 37 samples "earlier" from the source audio when recorded though an ADAT loopback (not the Loopback on TotalMix, but via real cable). The culprit, of course, is the fact that A) there is no ADDA operation on the ADAT channels, so there is no converter latency involved, and B) DAWs want, and so interfaces report only one global latency value, and this will always be the typically longer RTL of the analog paths.
Before I go into details and background below; let me ask the question / make the suggestion right up top:
Since we seem to be a small minority of people thinking and asking about this issue; let us do the bulk of the work for solving it. Let us do the required measuring. Only give us a simple sample delay tool in Totalmix which we can insert at the input. Make it part of Hardware Input Settings tab for example. So no advanced pinging tools, or compensation tricks and additional DAW reporting on RME's part. Things could become a bit trickier if the latency of the digital path ends up being greater than the analog path, but first things first: would this be as simple for RME to implement as it seems - a sample delay for Totalmix much like the ones found in some of our DAWs?
===
OK. So here is the long version for those who are interested:
This issue seems to have come up more through the use of digital I/O in insert paths where people started hearing phase alignment issues and comb filtering. Some people asked for driver level solutions and MC has invariably reasoned that A) this should rather be addressed at the DAW level and B) a driver-level solution could be confusing as well as more trouble than is worth and that this problem plagues only a handful of us picky souls 
So far so good.
My main interest is being able to record through my ADAT channels simultaneously with my analog channels without fretting the latency difference between their respective paths. And depending on the DAW, there are ways you can achieve such an alignment. With Cubase you can add a sample delay plug-in (I've used a free Voxengo tool) at the input channel and that'll do it - nice and simple even if this requires some manual measurement and some care. Likewise, with Logic you can add the relevant input channel to the Environment and insert the sample delay plug-in that is already part of Logic. This approach guarantees that the sample delay will only come into play during recording.
Now, Pro Tools is a different story. There we don't get to have separate insertion points for recording and playback. So should you insert a time adjuster plug-in during playback, this might keep you going, but you have to always take more care when handling such tracks. Should you duplicate tracks, move audio etc, your playback insert might get forgotten. Also, since you are delaying the signal at playback time and not recording an already delayed signal, your audio time stamp will not be accurate to begin with. I've tried emulating the input delay approach through an Aux Input (Source to Aux via loopback cable, Time Adjuster as Aux Insert, Aux to Destination via internal bus) but I couldn't record the signal for some reason. In any case even if one could solve the issue in PT, these are all patch style solutions.
Previously suggested solutions requested that e.g.:
At least if the RME Driver would report Digital latency (as a user selectable option), Loopback would be close to accurate (1 sample off IIRC due to the routing) and external Analog Loops would be able to be measured with the Steinberg ping tool with a positive offset.
to which MC replied:
And how many trouble would we get adding such an option with all its problems? ... Are you aware that the change from one setting to the other requires you to exit the DAW, restart, ping again? I think you better start a petition to bother ALL DAW software companies to get their act together and react on these real-world problems (different latencies on different I/Os) in a user-comfortable way. And then again - who notices (not measures) these small deviations?
I don't think there's a need for the RME driver to report digital latency. For this, RME would necessarily have to build a loopback ping into Totalmix, and if they wanted to implement the solution in a transparent manner, they would make this tool invisible and under the hood. Then they could be subject to a sh**storm of queries regarding this converter and that delay not being compensated for accurately etc.
