Audio Interface - Low Latency Performance Data Base :

[soundpalace]

Got a reply from Echo regarding the latency reporting and they are indeed working on it:

We're working on a new FireWire audio driver that should have a much more predictable input and output latency. Once we get that sorted out, we are planning to revisit this issue and make sure that our driver is reporting the correct latency for all the FireWire devices.

I wonder where the Audiofire would be on the list after this driver update, only time will tell

Cheers
soundpalace

[D.Don]

Originally Posted by soundpalace

Got a reply from Echo regarding the latency reporting and they are indeed working on it:

We're working on a new FireWire audio driver that should have a much more predictable input and output latency. Once we get that sorted out, we are planning to revisit this issue and make sure that our driver is reporting the correct latency for all the FireWire devices.

I wonder where the Audiofire would be on the list after this driver update, only time will tell

Cheers
soundpalace

Well done! This is indeed interesting!!!

(I'm in the market for at least 2 AF12 during the next months)...

[TAFKAT]

Originally Posted by soundpalace

Got a reply from Echo regarding the latency reporting and they are indeed working on it:

We're working on a new FireWire audio driver that should have a much more predictable input and output latency. Once we get that sorted out, we are planning to revisit this issue and make sure that our driver is reporting the correct latency for all the FireWire devices.

I wonder where the Audiofire would be on the list after this driver update, only time will tell

Hey S,

So they are saying its only reporting incorrectly in Cubase and that it isn't in fact double buffering on playback.

Only way to be sure is to use a manual ping test in Cubase itself and see whether that is the case in this instance , also, the PCI driver is also reporting the same behaviour its not just the FW driver.

You can do the manual ping test yourself with your Gina 3G and that will give us the answer.

Re where the AudioFire will be on the list if the output was reporting the same as the input in Cubase, its easy enough to work out as only the RTL % is effected, the performance results for the 3 respective benchmarks will remain the same.

Comparative RTL would be .74 up from .51 , LLP would be 5.89 up from 4.46.

[AwwDeOhh]

Could it be which version of Cubase is being used?


FWIW, i have an Echo AF4 and a RME FireFace 400.
On the same computer; i can only go as low as 256 buffer setting (without glitch) with the AF4,
the RME i can go as low as 32. (though not for more one or two tracks, i usually have it set to 64+ for tracking)

The Echo is a decent interface for the price, but i'm in love with my RME!

[redddog]

So the Latency Performance still blows.

But does it have to? What would be the reason why they would need to double their latencies vs everyone else? What would it take to improve it?

Thanks again guys. I'm amazed at how smart y'all are.

[soundpalace]

Is the performance of the Fireface UC expected to be on par with the Babyface results?

[soundpalace]

Looking at these results again, I wonder if the MBox Pro 3 is actually reporting the correct in & out latency values, they seem a bit too good to be true

Since I personally am only interested in output latency performance (e.g. EDM production with VSTs & VSTis), I have performed some recalculations based on the following formula:

Output Latency Performance = (RXC + CV + NCV ) / Output Latency

This ensures that the output latency is factored against the amount of instances possible.

Here are the results I calculated for the interfaces I was interested in:

RME AIO (MC off)

Buffer Setting - Rating
64 - 175
128 - 169
256 - 163

MBox 3 Pro

Buffer Setting - Rating
64 - 188
128 - 183
256 - 171

RME Babyface (should be same as Fireface UC too)

Buffer Setting - Rating
64 - 154
128 - 157
256 - 162

RME Fireface 800 (should be the same as Fireface 400 too)

Buffer Setting - Rating
64 - 143
128 - 143
256 - 146

The interesting thing when approaching it from this angle is that the RME USB interface do outperform the Firewire ones. However, in addition, the MBox 3 Pro outperforms the PCIe solution.

Either I've done something reaalllyy silly or The MBox is lying to us

Any chance you could measure the latency of the MBox 3 Pro using the latency tool?

Cheers
soundpalace

[soundpalace]

Here's my output, based on your excellent work! Higher overall ratings are better.



Cheers
soundpalace

[TAFKAT]

Hey S,

I have noted that I suspect that the Mbox /M-Audo and quite a few others are not reporting AD/DA , I'll amend those RTL figures when I get some time to do the retesting , however it will not change the ratings by a huge amount using my methodology

No disrespect, but I'm not really getting your rating system as combining values of numbers of plugins and notes of polyphony and then dividing it by the output latency is not really viable IMO.

Why don't you just use the available % data for the respective benchmarks and then use a comparative output value instead of the RTL as a % against the baseline ( what ever you choose to be the baseline ) , and see what you come up with. That is the methodology I have used.

i.e. RXC % + CV % + NVC % = Combined % / 3 to obtain Average %

Then calculate the output latency % value against your chosen baseline

Multiply the average % of the 3 benchmarks by the output % and get a rating - which will be in more in keeping with my LLP methodology.

I see you also capped the VI results at 256, which is fine for your personal investigation, but I purposely used the 512 setting on the VI test because I experienced a large variable across interface even at that latency.

[soundpalace]

Originally Posted by TAFKAT

Hey S,

I have noted that I suspect that the Mbox /M-Audo and quite a few others are not reporting AD/DA , I'll amend those RTL figures when I get some time to do the retesting , however it will not change the ratings by a huge amount using my methodology

No disrespect, but I'm not really getting your rating system as combining values of numbers of plugins and notes of polyphony and then dividing it by the output latency is not really viable IMO.

Why don't you just use the available % data for the respective benchmarks and then use a comparative output value instead of the RTL as a % against the baseline ( what ever you choose to be the baseline ) , and see what you come up with. That is the methodology I have used.

i.e. RXC % + CV % + NVC % = Combined % / 3 to obtain Average %

Then calculate the output latency % value against your chosen baseline

Multiply the average % of the 3 benchmarks by the output % and get a rating - which will be in more in keeping with my LLP methodology.

I see you also capped the VI results at 256, which is fine for your personal investigation, but I purposely used the 512 setting on the VI test because I experienced a large variable across interface even at that latency.

Hey mate, thanks for the reply.

You are right, these results were pretty much for my personal needs but I thought I'd share anyway to point out the MBox's unusually high rating.

No disrespect taken at all, I understand your approach and think it's great. However, I always tend to think of things as factors of others.

e.g.

If you drive 100km at 50km/hour, then the total time taken would be

100/50 = 2 hours

If you create a total of 200 instances of plugins with a 10ms latency, then the system is as good as:

200 / 10 = 20 units

But if you can create only 200 instances with a 20ms latency, then your system is not quite as good:

200 / 20 = 10 units

Anyways, as I mentioned, this is just how my brain works I don't tend to use anything as a benchmark per se, each device simply has a "goodness" factor which can be your own form of units. This is similar to Passmark benchmarks (http://www.cpubenchmark.net/).

Keep up the great work!

[tobto]

I surpised of RME as I got one (old ADI8PRO). Also, I see there is no real 'Zero latency interface' on the market for overdubbing as it was in Analog Tape Age? Onyx?

[TAFKAT]

Originally Posted by soundpalace

No disrespect taken at all, I understand your approach and think it's great. However, I always tend to think of things as factors of others.

e.g.

If you drive 100km at 50km/hour, then the total time taken would be

100/50 = 2 hours

Hey S,

Well think of it this way , in your example you have 2 factors - 100km which is distance covered ( km ) divided by speed which is measured by distance / time (km/hr), which makes sense because the unit of measurement is based on appropriate variables.

Plugin / polyphony per ms really doesn't correlate in the same way, however if you use the % values which correlate to their own respective results per benchmark and use those as the factors, you'll get results that make more sense IMO.

Re the Passmark synthetic benchmarks, hmmm, they have never had any significant correlation to DAW performance, if they did the current AMD architecture would be a lot closer in comparative performance to the Intel architecture , which they certainly are not. It was one of the main catalysts for developing the DAW specific benchmark methodologies so we had something at least relevant and closer to our specific stressing environment.

@ tobto,

What you are referring to is RME's original Zero Latency Monitoring ( ZLM ) , that is just another term for ASIO Direct Monitoring ( ADM ) - which simply passes the signal from the AD thru to the DA , so the only latency is the inherent delays of the actual converters . That is still available in DAW hosts that have facilitated ADM and is also available via the DSP powered Monitoring Mixers that most if not all audio interfaces have.

That is different to what I am referring to in these tests. In this instance the latency being referred to is that imposed by the actual input and playback buffers of drivers when playing VI's in real time or monitoring via software with plugins within the DAW hosts.

The 2 are totally different and unrelated.

FWIW : It was never Zero Latency , but it is very low. The current ASIO Direct Monitoring / Hardware Direct Monitoring Latency for the RME HDSPe / ADI8 combo is around 28 samples - thats 14 samples for the AD and 14 samples for the DA - total .635 ms RTL.

[TAFKAT]

Originally Posted by TAFKAT

Hey S,

I have noted that I suspect that the Mbox /M-Audo and quite a few others are not reporting AD/DA , I'll amend those RTL figures when I get some time to do the retesting , however it will not change the ratings by a huge amount using my methodology

Quick heads up,

MboxPro 3 was confirmed using the RTL Utility to be not reporting AD/DA , the total added samples to RTL was * 38 samples ( .86 ms), which would probably be 19 samples ( .43 ms ) respective for AD and DA , but no definitive way of checking that with the RTL Utility.

* That is a pretty impressive latency value for the AD/DA's.

Profire 610/2626 however are reporting the AD/DA.

MboxPro 3 LLP rating has dropped from 7.76 to 7.27.

I'll amend the charts when I get some time.

[tobto]

2tafcat
Thanks for replying! I just wanted to tell that recording 8 tracks at once (band) is awesome with some interface. But when you play to overdub some tracks you got issues. Technical data relates to UI. If you / me feel uncomfortable to play music, gear isn't right built. Well, designed to be.

[zephonic]

Originally Posted by TAFKAT

Quick heads up,

MboxPro 3 was confirmed using the RTL Utility to be not reporting AD/DA , the total added samples to RTL was * 38 samples ( .86 ms), which would probably be 19 samples ( .43 ms ) respective for AD and DA , but no definitive way of checking that with the RTL Utility.

* That is a pretty impressive latency value for the AD/DA's.

Profire 610/2626 however are reporting the AD/DA.

MboxPro 3 LLP rating has dropped from 7.76 to 7.27.

I'll amend the charts when I get some time.

Is that extra 38 samples always the same, irrespective of sample rate/buffer size?

[TAFKAT]

Originally Posted by zephonic

Is that extra 38 samples always the same, irrespective of sample rate/buffer size?

It will remain consistent in regards to sample buffer but not for sample rate , that value will change accordingly for the respective sample rates.

For 44.1 used in the testing - 38 samples is the actual ( added ) RTL latency of the AD/DA irrespective of the sample buffer.

So for every listed RTL value for the MBox Pro in the previous chart, add 38 samples / .86 ms

Some audio interfaces include the AD/DA value when reporting the latency to the ASIO Host , some do not , so I'll be double checking all interfaces in future / where possible to get further clarification.

[Timur Born]

I did a very quick test of the old FW based MOTU Ultralite. On Windows it reports about 48-56 samples less (depending on the SR) round-trip than is really happening, on OS X it reports about 75 samples less. Adding these missing samples makes it still perform slightly better (around 0.25 ms) than a Babyface on OS X, but a lot worse on Windows (around 5.4-5.7 ms depending on the SR).

[TAFKAT]

Originally Posted by Timur

I did a very quick test of the old FW based MOTU Ultralite. On Windows it reports about 48-56 samples less (depending on the SR) round-trip than is really happening, on OS X it reports about 75 samples less. Adding these missing samples makes it still perform slightly better (around 0.25 ms) than a Babyface on OS X, but a lot worse on Windows (around 5.4-5.7 ms depending on the SR).

Hey Timur,

Thanks for that.

I would have thought that the variance would be down to the driver not reporting the AD/DA ( as I found on the PCI driver ) , but the difference between Win7 and OSX kind of goes against that premise.

How are you measuring the actual RTL ?

[redddog]

So the Latency Performance on the AF12 still blows.

But does it have to? What would be the reason why they would need to double their latencies vs everyone else? What would it take to improve it?

[Timur Born]

Hey Tafkat,

I was lazy and lacked time, so I just used the latency measurement set of Ableton Live. It's a simple loop-back recording of a sinusoid where you either manually shift the recorded clip back/forth to match the original clip or you change the manual delay compensation value in preferences (can be done in samples or ms).

Live's graphical clip-view is *not* fully sample-accurate, especially when it comes to where on the time-line a sample is placed (there are various circumstances that make the graphic shift back or forth a bit). But my experience is that with fresh recording (the premade set) it's only 1 sample off what the RME driver reports, which usually is accurate when measured with Reaper.

[TAFKAT]

Originally Posted by redddog

So the Latency Performance on the AF12 still blows.

But does it have to? What would be the reason why they would need to double their latencies vs everyone else? What would it take to improve it?

Hey R,

The jury is still out on the double buffering being reported in Cubase , really need to do a manual loop back test of some sort from within Cubase to be sure.

The Echos reporting different playback latencies to all the other apps is a strange anomaly that I have not found on any other interface , and what makes it even stranger is that if it is reporting incorrectly by that amount, I would have thought it be throwing offsets out with the application.

Still digging ..

@Timur,

Cool, as I noted earlier I do need to look into developing a session to be able to some manual loop back testing in Cubase / Reaper just to dot the i's further.

BTW: I have a new version of the RTL Analyser Utility in the works which reports not only the calculated RTL, but also what the ASIO driver is reporting outside of the DAW host . The last point is interesting as we have measured small discrepancies of the reported RTL depending whether the DAW host is running or not , which open up a whole new area of investigation ..

The fun continues.

P.S- I saw you post over at the RME forum, you didn't know I was a Professional DAW builder ?

I need to work on lifting my profile ... LOL

[redddog]

Great, Vin.

Really appreciate all the work on this.

The AF12 sounds great and is super stable. Just really curious why they would accept such poor latency performance if it could be improved (by a friggin ton, as it turns out).

Thanks again, bro.

[TAFKAT]

Hey All,

I haven't had a lot of time for testing lately but I thought it would be good to post the latest batch of results and amendments that I have collated since the last posting.



Interfaces Added :

MOTU - 828 Mk3 - FW : Respectable performance across the board, only caveat being that it uses double buffering on playback which effects its RTL.

Presonus Studio Live 16.4.2: Another unit using the now familiar Dice OEM controller/driver solution , performance being on par with other interfaces using the identical controller /driver.

Focusrite Saffire 6 USB : Worst performing and highest I/O and RTL of any interface tested , needless to say this did not rate well. * Testing and results by Scan U.K *

Amended Results:

AVID Mbox Pro 3 , Focusrite Saffire 56 , Midas Venice F - all units were not reporting AD/DA , RTL has been calculated using the utility, RTL and LLP Ratings have been adjusted accordingly.

[Masaaki]

Thank you for the updates.

I hope we see data on some new USB2.0 product lines, like Roland Octa/quad capture, Presonus (forgot the name), and Focusrite Scarlett lines. People are asking a lot about the performance of these new products. But maybe drivers are not stable yet...

[D.Don]

Originally Posted by soundpalace

Got a reply from Echo regarding the latency reporting and they are indeed working on it:

We're working on a new FireWire audio driver that should have a much more predictable input and output latency. Once we get that sorted out, we are planning to revisit this issue and make sure that our driver is reporting the correct latency for all the FireWire devices.

I wonder where the Audiofire would be on the list after this driver update, only time will tell

Cheers
soundpalace

There's a new driver up now, 5.7!

Is it possible that we can get this new one tested?

[TAFKAT]

Originally Posted by D.Don

There's a new driver up now, 5.7!

Is it possible that we can get this new one tested?

No problem, luckily I still have the test unit on loan , so I'll run it thru its paces with the new driver when I get some clear air.

@ Masaaki,

I'll be covering as many of the new USB2 interfaces as I can get my hands on.

[analogholic]

@TAFKAT

Can you check

Roland Quadra/Octa Capture

Focusrite Scarlett


Thanks!

Thinking of buying one of these, but want to wait for your test.

[D.Don]

Originally Posted by TAFKAT

No problem, luckily I still have the test unit on loan , so I'll run it thru its paces with the new driver when I get some clear air.

Rock'n'roll!

I may have asked this before, but I don't find the post, is there anything in these test results that would be comparable/equal if you did it in OS X on a mac instead? (I am OS X/Mac user).

[Masaaki]

I vote +1 this thread for sticky.

Much much more useful information than most of the threads about.....say SR, not to mention P/M threads. Know what I mean?

[TAFKAT]

Originally Posted by D.Don

Rock'n'roll!

I may have asked this before, but I don't find the post, is there anything in these test results that would be comparable/equal if you did it in OS X on a mac instead? (I am OS X/Mac user).

Hey D,

The benchmarks used are actually cross platform , with sessions for multiple DAW host , problem being whereas on Win7 there is some consistancy across the performance of the native DAW Hosts , on OSX its not as clear cut. All of these results are using Cubase , however if I tried to present the reports using Cubase on OSX I would get lynched I suspect.

OSX is also a tougher call because arguably the best performing DAW Host - Logic , uses a Hybrid playback engine which has a default 1024 playback buffer , so the methodology I have used doesn't really translate as the performance results are based on playback buffer size.

Having said that, there was a great post earlier on in this thread from jonasbj who posted a stack of info on RTL for a range of interface on OSX , not quite as detailed, but still good info. Post is Here