Driver 3.6.8.1410 latency measurements

[pcournoyer]

I finally got a chance to install the new 1410 drivers that appeared to have good review from other users on this forum.

For comparison, I first measured latency on my previously installed driver version which was 3.6.8.1360 (actually MOTU console reports it as being 3.6.8.1359...I guess somebody forgot one of the step of the software delivery process!!).

All latency measurement done using Plogue Bidule using a 44.1KHz clock on a 828mk3 with firmware V1.06.

3.6.8.1360 round-trip latency measurements using analog loopback:
Buffer size 64 samples: total latency 362 samples = 8.21 ms.
Subtracting Bidule's own buffer delay of 64 samples (1.45 ms) gives a driver round-trip delay of 6.76 ms.

Buffer size 128 samples: total latency 618 samples = 14.01 ms.
Subtracting Bidule's own buffer delay of 128 samples (2.91 ms) gives a driver round-trip delay of 11.11 ms.

Now, moving on to 3.6.8.1410:
Buffer size 64 samples: total latency 297 samples = 6.73 ms.
Subtracting Bidule's own buffer delay of 64 samples (1.45 ms) gives a driver round-trip delay of 5.28 ms.

Buffer size 128 samples: total latency 489 samples = 11.09 ms.
Subtracting Bidule's own buffer delay of 128 samples (2.91 ms) gives a driver round-trip delay of 8.19 ms.

So, it seems that MOTU has cut back some of the extra buffering in 1410 with a 21% improvement at buffer size 64 and 26% improvement at buffer size 128.

I also did a latency test using ADAT loopback to evaluate the additional latency for A/D and D/A conversions: 25 samples or 0.57ms for both D/A and A/D (loopback test).

So this is good news...


One bad news is that the input signals were messed up in Bidule. For example, MIC1 and MIC2 were previously the first 2 input signals and they are now the last 2!! Go figure why somebody would mess up the signal ordering in a new driver release...

Another interesting observation is that the actual latency of the interface + driver does not correlate with the buffer size. For example, at a buffer size of 64 samples, one would expect the round-trip delay to be around 128 sample = 2.91ms where in actuality it is 6.76ms or more than double the expectation. So, buffer size cannot be used to estimate real world performance since it appears manufacturer can add inordinate amount of extra buffering.

[Mark S]

Yes, the 3.6.8.x drivers add "safety" buffer. (for the MKIII hardware). Since I don't have MkIII hardware I'm staying put at 3.6.7.4