Quantcast
Audio Interface - Low Latency Performance Data Base - Page 39 - Gearspace.com
The No.1 Website for Pro Audio
Audio Interface - Low Latency Performance Data Base
Old 23rd December 2016 | Show parent
  #1141
Lives for gear
 
eightyeightkeys's Avatar
 
1 Review written
🎧 15 years
Quote:
Originally Posted by Bstapper ➡️
.....with a significant project load instead of a single 1khz sine wave.....
Load up about 50 tracks of pink noise, a few generic VSTi's, and try your test again. ....
Cheers,
Brock
Spot on. It's the way that the drivers perform, at a given buffer setting, with a "significant project load."
Old 23rd December 2016
  #1142
Gear Nut
 
🎧 5 years
OOPS something went wrong and the post that I was responding to (https://gearspace.com/board/12330177-post1139.html) didn't get quoted - sorry.

Brock,

No offense taken (or intended). IMHO this discussion is important so your participation/indulgence is greatly appreciated.

Note that it’s actually a square wave (which can provide a lot more diagnostic information than a sine wave). Since the 6i6’s performance is much better at 96k than at both 44.1k and 48k Samples/s (as shown below and documented at Measuring Latency, Scarlett 6i6, DiGiGrid, etc. - Avid Pro Audio Community), it likely isn’t an intentionally “colored mic” input. Also, as DAW Plus pointed out, the driver shouldn’t impact audio performance if it’s working properly. So, unless the apparent hardware design/implementation deficiencies were corrected in the 2nd generation, they’re likely still there. Maybe someone will check it! Note though that the 2nd generation’s ASIO driver reportedly still has problems with Pro Tools. Apparently only RME and ASIO4ALL (with large buffers) don’t. You didn't use Pro Tools for your comparisons did you?

1st Generation Focusrite Scarlett 6i6 - 2nd Loopback at 48k Samples/s

Audio Interface - Low Latency Performance Data Base-beta-6i6-48-khz-2nd-loopback.jpg

1st Generation Focusrite Scarlett 6i6 - 2nd Loopback at 96k Samples/s
Audio Interface - Low Latency Performance Data Base-beta-6i6-96-khz-2nd-loopback.jpg

Would tests similar to those being used for the computer performance benchmark testing referenced at https://gearspace.com/board/12107767-post72.html be a suitable alternative to your proposed tests?
Attached Thumbnails
Audio Interface - Low Latency Performance Data Base-beta-6i6-48-khz-output-1st-loopback.jpg   Audio Interface - Low Latency Performance Data Base-beta-6i6-48-khz-2nd-loopback.jpg   Audio Interface - Low Latency Performance Data Base-beta-6i6-96-khz-output-1st-loopback.jpg   Audio Interface - Low Latency Performance Data Base-beta-6i6-96-khz-2nd-loopback.jpg  

Last edited by AmackG; 24th December 2016 at 06:16 PM.. Reason: Clarify, link to Brock's post, and correct heading for 1st image
Old 25th December 2016
  #1143
Lives for gear
 
TAFKAT's Avatar
 
🎧 15 years
Sigh,

I noted a few weeks back my thoughts on the derailing of this thread regards ASIO4All, unfortunately it seems that it has fallen on deaf ears and is now being shifted and derailed even further. Waveform loopback results ?! , I mean really, that has absolutely nothing to do with driver performance.

Seriously guys, take the discussion elsewhere .

I don't know how many times I can say this, Protools , DUC, ASIO4All has no relevance here. I am not open to debate on this, I will not engage and I respectfully ask others reading in to do the same.

Lets steer this back on topic , please.

Last edited by TAFKAT; 25th December 2016 at 08:57 AM..
Old 25th December 2016 | Show parent
  #1144
Lives for gear
 
🎧 5 years
Quote:
Originally Posted by TAFKAT ➡️
Quick heads up.

Focusrite have released a revised driver ( 2.1.5 ) with some amendments to the performance concerns I had noted and forwarded to them.

I'll get some numbers up over the next few days.

Any news regarding Focusrite's drivers ? (especially for the TB interfaces - on a PC)

Is it a viable solution against RME ? (considering it costs a lot less)
Old 25th December 2016 | Show parent
  #1145
Gear Head
 
🎧 10 years
Quote:
Originally Posted by A Tan ➡️
Any news regarding Focusrite's drivers ? (especially for the TB interfaces - on a PC)

Is it a viable solution against RME ? (considering it costs a lot less)
Yes me too i wonder about the focusrite sec gen on the usb side.
Old 25th December 2016 | Show parent
  #1146
Gear Nut
 
🎧 5 years
Quote:
Originally Posted by TAFKAT ➡️
Sigh,

I noted a few weeks back my thoughts on the derailing of this thread regards ASIO4All, unfortunately it seems that it has fallen on deaf ears and is now being shifted and derailed even further. Waveform loopback results ?! , I mean really, that has absolutely nothing to do with driver performance.

Seriously guys, take the discussion elsewhere .

I don't know how many times I can say this, Protools , DUC, ASIO4All has no relevance here. I am not open to debate on this, I will not engage and I respectfully ask others reading in to do the same.

Lets steer this back on topic , please.
Sorry again!! I was just trying to understand why some people have such a negative opinion of ASIO4ALL. I previously demonstrated (and posted) that its performance on an updated approximation of your ""DAWbench DSP Universal - 2104" RXC baseline test (http://www.dawbench.com/benchmarks.htm) was quite respectable. So, I attempted to address any potential concerns regarding the overall performance of an audio interface based on its use in conjunction with a computer's onboard sound "card".

To me this is still an open discussion, but I'll honor your wish and open a new thread for further discussion. Can I put a link to that new thread here?
Old 1st January 2017
  #1147
Lives for gear
 
Clockwise's Avatar
 
🎧 5 years
A longtime owner of E-MU 1616m PCIe here.

Been wondering how this interface compares in term of latency as all the other aspects are nearly perfect as a desktop interface (conversion quality, flexible routing with Patchmix, onboard fx, number of i/o and the slick design).

So just donwloaded the RTL Utility, patched the output to the input and measured the RTL.

What a.... The measured RTL at 44.1khz with 128 buffer is 8.007ms which is better than some of the RME interfaces. Sorry, let me correct this. There is only one RME interface that has better performance than the 1616 PCIe at 128 buffer, which is HDSPe AES. Does that impress you?

The downside of 1616 PCIe in terms of latency performance is that the smallest buffer is limited to 88 samples at 44.1khz (6.081ms RTL) and 96 at 48khz (5.880ms RTL). The shortest RTL I could achieve with 1616 PCIe was 5.156ms at 96khz with 192 buffer.

I was thinking of buying a better interface when I upgrade my PC, but seems like it won't be in another year or two!
Old 2nd January 2017 | Show parent
  #1148
Lives for gear
 
DAW PLUS's Avatar
 
🎧 10 years
Quote:
Originally Posted by Clockwise ➡️
What a.... The measured RTL at 44.1khz with 128 buffer is 8.007ms which is better than some of the RME interfaces. Sorry, let me correct this. There is only one RME interface that has better performance than the 1616 PCIe at 128 buffer, which is HDSPe AES. Does that impress you?
Good score. Analog or digital loopback?
Quote:
The downside of 1616 PCIe in terms of latency performance is that the smallest buffer is limited to 88 samples at 44.1khz (6.081ms RTL) and 96 at 48khz (5.880ms RTL). The shortest RTL I could achieve with 1616 PCIe was 5.156ms at 96khz with 192 buffer.

I was thinking of buying a better interface when I upgrade my PC, but seems like it won't be in another year or two!
You forget one thing: is it usable at that latency? Because that is what Vin tested here, not just the RTL itself. Low latency is not usable when you cannot play back a small project without dropouts, which is the issue with most interfaces aside from RME.

It is about the latency vs performance ratio, not just latency.

That being said, the EMU has a very positive user base, so regardless of the actual performance, its price/performance ratio is already great. However, without a benchmark, it is hard to put it in perspective towards other interfaces.
Old 2nd January 2017 | Show parent
  #1149
Lives for gear
 
Clockwise's Avatar
 
🎧 5 years
Quote:
Originally Posted by DAW PLUS ➡️
Good score. Analog or digital loopback?
Analogue. I might try the S/PDIF loopback later on.

Quote:
You forget one thing: is it usable at that latency? Because that is what Vin tested here, not just the RTL itself. Low latency is not usable when you cannot play back a small project without dropouts, which is the issue with most interfaces aside from RME.

It is about the latency vs performance ratio, not just latency.
Here's a problem. My PC is so underspec'd to be able to show any comparable test result against modern rigs like Intel i7 or oven i5.

Maybe someone else could pick up a 2nd hand EMU PCIe interface and run a test.

Quote:
That being said, the EMU has a very positive user base, so regardless of the actual performance, its price/performance ratio is already great. However, without a benchmark, it is hard to put it in perspective towards other interfaces.
Agreed. And it's a dying horse sadly. But I'd say that this would be one of the best interfaces for those with Win7. Measurement-wise (S/N, THD and Crosstalk), it's still even comparable to the latest UA, MOTU and RME interfaces.
Old 2nd January 2017
  #1150
Lives for gear
 
🎧 10 years
@ Clockwise

EMU interfaces were really good, it was great "package" of audio performance, features and price. I've had EMU 1212 PCI up to last year in my home machine (used mostly for testing, development etc. where horsepower isn't as important).
I've upgraded it to RME AIO quite recently. I'm in similar situation like you, that particular computer is very low specs compared to current standard, so it was quite silly to do Dawbench here.
A you've also find out, RTL figures compared to AIO were very similar at comparable buffer lengths, but just empirically when playing with different workloads and instruments, driver efficiency is typically one "notch" better than with EMU.. eg. something which crapped out and need 192 or 256, works well also at 128.. something with required 128 can be used at 64.. etc. To me it was apparent at this lowly box.. maybe the results will be different with the computer having more performance headroom, however to me RME is still bit better at given situation. I plan to get new computer someday during this year, but unfortunately it looks like it won't be the setup with legacy PCI slot, so I couldn't test that again.
Otherwise I agree with you, EMU was in a position to be a really nice choice for many folks out there, product were great IMO.

Michal
Old 2nd January 2017
  #1151
Lives for gear
 
Clockwise's Avatar
 
🎧 5 years
Nice post, msmucr! I'm sure you are enjoying the RME AIO now as the driver seems very stable and well coded.

Another advantage of modern interfaces such as RME stuff is that the buffer can be lowered down to 64 or 32 at higher sample rate, which gives much shorter latency. This makes a greater difference when tracking with Native plugins engaged or playing VIs live. It would mean that you need a powerful computer to keep up with the processing, and here's where the driver efficiency matters more. I'd love to play some software pianos on the latest machine with shortest latency available.
Old 2nd January 2017
  #1152
Lives for gear
 
TAFKAT's Avatar
 
🎧 15 years
Happy New Year to All.

Michal and Leon beat me to the punch.

I never had the opportunity to test the EMU PCI/PCIe units, not overly common here in Australia unfortunately.

Just to reiterate what the guys have already noted, LLP is more than just the actual latency achieved , its also the efficiency at those latencies. All of the PCIe cards listed have good RTL, even the budget Julia XTe card , and its a combination of the delivered I/O latency and the efficiency which is the true measure of the LLP.

One of the practices of the manufacturers is to quote I/O and RTL at higher sample rates to give a wow factor, some even just quote the lowest available latency , without listing the other/workable latencies , which in some cases have increased measurably on later drivers.

I have a report and overview in the works which will include some results for some new interfaces and also updated drivers for some existing. Updated drivers do not mean better performance in some instances and I will be amending numerous interfaces with reduced LLP ratings as a result.

This is a concerning trend that has increased recently ( since W10 ? ) and is associated directly with the 3rd party OEM driver providers that the manufacturers are reliant on. I do have to wonder whether the coders are actually working with the drivers in the field or are simply code jockeys to be honest.

Stay Tuned.

Old 2nd January 2017
  #1153
Lives for gear
 
Clockwise's Avatar
 
🎧 5 years
Just tested the S/PDIF i/o of E-MU 1616m PCIe.

The RTL is 6.168ms at 44.1khz with 128 buffer.

Out of curiousitiy, also measured the RTL at 48khz and 96khz with smallest buffer available.

It's 4.464ms at 48khz with 96 buffer, and 4.229ms at 96khz with 192 buffer.

I didn't realise AD/DA stages add about 1.4-2ms of latency. Even though such figures would vary on interfaces, good to know for a future reference.
Old 3rd January 2017
  #1154
Lives for gear
 
🎧 10 years
Hello Vin,

Happy New Year also to you
I'm looking forward to your new report and thank you for the time, you're spending with it.

I see what you mean with recent driver releases, for example I had some spare day just before Christmas so I've grabbed some available 1st gen. Scarlett 2i4 and tested it with old (2.5), old beta (3.x) and the latest beta drivers (their 4.x).. just because I was curious what's going on
It's indeed quite a variance with both performance and various operational woes (from sample rate changes, through some particular app issues to MIDI SYSEX handling) with this original Scarlett. It's definitely not possible to tell one is clearly better than other (if someone would ask me, which release I'd recommend, it will be probably questionnaire about what exactly he's going to do ).
I've reported something to their beta mail, so maybe some points can be helpful to them.. In this particular case, I'd be glad, if their USB drivers could be rather more solid, not that I'm primary user for my own things, but as there is so many sold units out there (hardware isn't bad, it's good startup interface), it would make many folks happy, I suppose
With regards to repackaging of 3rd party drivers, some vendors apparently do better job than others.. I'm not sure about recent Focusrite development, but to me their latest releases looks more like in-house work, which might be better for future development and control about that software (just assuming that, they had to develop own drivers for Clarett for Windows, so maybe they'll also reuse parts of that codebase for the USB drivers.. also newer betas has some bugs, which generic Thesycon doesn't have, so assuming it's rather something "homegrown"). So let's see.
I can imagine, sometimes it's difficult decisions with such development and in few cases, I believe, it can be wiser thing to use just relatively untouched 3rd party drivers for class compliant devices, because possible worse performance can be less evil, than WDM/ASIO compatibility issues.

All the best,

Michal
Old 3rd January 2017 | Show parent
  #1155
Lives for gear
 
🎧 10 years
Quote:
Originally Posted by Clockwise ➡️
I didn't realise AD/DA stages add about 1.4-2ms of latency. Even though such figures would vary on interfaces, good to know for a future reference.
Well, it depends mainly on used converter chips and its setup.
From say 2008 many vendors added selectable options for shorter (less FIR taps) reconstruction/decimation filters to their chips. So for instance AKM has 7 and 12 samples of group delay for A/D and D/A, which is rather big improvement to previous chip generations, which was used in EMU.
However sometimes designer don't choose that, as those shorter filters aren't necessarily for free and filter performance can be bit worse (stopband attenuation, more ripple in passband), or it's simply picked by ear at the end (although this specific filter mangling is more used in hifi-segment). So as you've said, it might still vary.

Michal
Old 3rd January 2017 | Show parent
  #1156
Lives for gear
 
Clockwise's Avatar
 
🎧 5 years
Quote:
Originally Posted by msmucr ➡️
Well, it depends mainly on used converter chips and its setup.
From say 2008 many vendors added selectable options for shorter (less FIR taps) reconstruction/decimation filters to their chips. So for instance AKM has 7 and 12 samples of group delay for A/D and D/A, which is rather big improvement to previous chip generations, which was used in EMU.
However sometimes designer don't choose that, as those shorter filters aren't necessarily for free and filter performance can be bit worse (stopband attenuation, more ripple in passband), or it's simply picked by ear at the end (although this specific filter mangling is more used in hifi-segment). So as you've said, it might still vary.

Michal
Thanks for sharing your knowledge, Michal! I'm an absolute layman when it comes to electronics but with explanation, still capable of understanding what element of an interface affects the overall performance, so great read indeed.

On top of real world performance (usable buffer size with small project on a DAW as DAW PLUS has suggested), it may be helpful to list analogue and digital i/o RTL measurements so that the AD/DA latency can be revealed.
Old 3rd January 2017 | Show parent
  #1157
Lives for gear
 
🎧 10 years
Quote:
Originally Posted by Clockwise ➡️
Thanks for sharing your knowledge, Michal! I'm an absolute layman when it comes to electronics but with explanation, still capable of understanding what element of an interface affects the overall performance, so great read indeed.

On top of real world performance (usable buffer size with small project on a DAW as DAW PLUS has suggested), it may be helpful to list analogue and digital i/o RTL measurements so that the AD/DA latency can be revealed.
You're true, the lower you go with buffers for shortest roundtrip delays, the more significant those inherent delays in converters are.
It is also generally important thing to realize, different types of I/Os at the interface has different roundtrip delays for its compensation at DAW. So for example if someone is using combination of built-in analogue I/Os and some external ADAT converter, recorded tracks can't be never perfectly aligned.
This is also related to ASIO capabilities, because only one common input and output latency can be reported from the driver to DAW.. it isn't possible to pass that information about every single channel from the interface.
Typically it's latency of analogue I/Os, which is being reported.
Normally it's not such big deal, if someone stick with the basic rule to don't use any delay sensitive channel groups (like surround set, multi-channel feed from one instrument, stereo pairs etc.) across multiple different converters. However when one is running out of inputs at small setup and has to combine everything usable together without another option, then it's always better to check that out and possibly manually offset captured tracks later, because the difference between inputs can be easily in milliseconds range.

Michal
Old 3rd January 2017 | Show parent
  #1158
Lives for gear
 
TAFKAT's Avatar
 
🎧 15 years
Quote:
Originally Posted by msmucr ➡️
With regards to repackaging of 3rd party drivers, some vendors apparently do better job than others.. I'm not sure about recent Focusrite development, but to me their latest releases looks more like in-house work, which might be better for future development and control about that software (just assuming that, they had to develop own drivers for Clarett for Windows, so maybe they'll also reuse parts of that codebase for the USB drivers.. also newer betas has some bugs, which generic Thesycon doesn't have, so assuming it's rather something "homegrown"). So let's see.
Hey Michal,

The Focusrite USB are definitely not Thesycon , they are significantly different in approach and delivery, however from my recent dealings with QA it was indicated that they are still working with a 3rd party OEM. I don't know exactly who that is tho.

Old 3rd January 2017 | Show parent
  #1159
Gear Nut
 
🎧 5 years
Quote:
Originally Posted by Clockwise ➡️
Just tested the S/PDIF i/o of E-MU 1616m PCIe.

The RTL is 6.168ms at 44.1khz with 128 buffer.

Out of curiousitiy, also measured the RTL at 48khz and 96khz with smallest buffer available.

It's 4.464ms at 48khz with 96 buffer, and 4.229ms at 96khz with 192 buffer.

I didn't realise AD/DA stages add about 1.4-2ms of latency. Even though such figures would vary on interfaces, good to know for a future reference.
If your interface supports direct monitoring, you'll probably find that the difference in the analog and SPDIF (and ADAT?) RTL measurements is approximately the same as that direct monitoring latency (DML).

You can easily measure DML by measuring the delay it adds to the "standard" analog RTL by putting it in a loopback path as follows. Externally connect an interface analog output to an analog input (for instance Out1 to In1) Internally route that input to another analog output (for instance Out2). Externally connect that output to another input (for instance In2) and measure that RTL (from Out1 to In2). Then, to calculate DML, subtract the "standard" analog RTL (Out1 to In1) from that RTL (Out1 to In2). The result is the interface's DML.

Last edited by AmackG; 4th January 2017 at 11:22 PM.. Reason: Fix procedure
Old 3rd January 2017 | Show parent
  #1160
Lives for gear
 
Clockwise's Avatar
 
🎧 5 years
Quote:
Originally Posted by AmackG ➡️
If your interface supports direct monitoring, you'll probably find that the difference in the analog and SPDIF (and ADAT?) RTL measurements is approximately the same as that direct monitoring latency (DML).

You can easily measure DML by measuring the delay it adds to the "standard" analog RTL by putting it in a loopback path as follows. Internally route one of the interface's inputs (like Input #1 ) to an output (like Output #2 ). Externally connect that output to another input (like Input #2 ) and measure that RTL (Output #1 to Input #2 ). Then, to calculate DML, subtract the "standard" analog RTL (like Output #1 to Input #1 with external connection from Output #1 to Input #1 ). The result is the interface's DML.
Thanks, AmakG.

Just tested the loopback RTL by patching one of the stereo ASIO outs to ASIO ins. The RTL Utility reported the latency of 4.208ms (with total buffer of 202 samples) at 48khz with 96 buffer. So the reported internal buffer of 202 samples - (2 x 96) samples = 10 samples, which means the driver adds the delay of 10 samples at this setting.

Now measure the analogue loopback RTL. It's 5.864ms (with total buffer of 284 samples), which means the latency at DA/AD conversion is 82 samples or 1.656ms (41 samples at each conversion?).

For some reason there are uncertainties of upto 100 microseconds when measuring the analogue RTL. I wonder what affects the performance here.
Old 3rd January 2017 | Show parent
  #1161
Lives for gear
 
TAFKAT's Avatar
 
🎧 15 years
Quote:
Originally Posted by Clockwise ➡️

Just tested the loopback RTL by patching one of the stereo ASIO outs to ASIO ins. The RTL Utility reported the latency of 4.208ms (with total buffer of 202 samples) at 48khz with 96 buffer. So the reported internal buffer of 202 samples - (2 x 96) samples = 10 samples, which means the driver adds the delay of 10 samples at this setting.

Now measure the analogue loopback RTL. It's 5.864ms (with total buffer of 284 samples), which means the latency at DA/AD conversion is 82 samples or 1.656ms (41 samples at each conversion?).

For some reason there are uncertainties of upto 100 microseconds when measuring the analogue RTL. I wonder what affects the performance here.
The Panel Buffer Settings of 032/064/128 etc are nominal, no interface will deliver the exact nominal latency , there will always be a small number of additional samples to navigate Protocols , DSP and even safety buffers to smooth out playback. This is normal.

Some integrated interfaces do not report the AD/DA to the driver , using external AD/DA cannot report the AD/DA but the higher end I have listed ( RME/Lynx ) are within a 10-12 sample range , so unnoticeable for the most part. As Michal noted earlier, if using external AD/DA in conjunction with internal and they have different latency values, you need to be more diligent if the external have higher/lower AD/DA.

It is not uncommon for AD/DA on some interfaces to have latency around 30-40 samples , so your interface is in range.


Old 4th January 2017 | Show parent
  #1162
Gear Nut
 
🎧 5 years
Quote:
Originally Posted by Clockwise ➡️
Thanks, AmakG.

Just tested the loopback RTL by patching one of the stereo ASIO outs to ASIO ins. The RTL Utility reported the latency of 4.208ms (with total buffer of 202 samples) at 48khz with 96 buffer. So the reported internal buffer of 202 samples - (2 x 96) samples = 10 samples, which means the driver adds the delay of 10 samples at this setting.

Now measure the analogue loopback RTL. It's 5.864ms (with total buffer of 284 samples), which means the latency at DA/AD conversion is 82 samples or 1.656ms (41 samples at each conversion?).

For some reason there are uncertainties of upto 100 microseconds when measuring the analogue RTL. I wonder what affects the performance here.
This stuff is pretty new to me, so I'm sorry if these are stupid questions. Are stereo ASIO in and out the same as ADAT in and out? Do they undergo less processing in the interface than SPDIF (to account for your 4.464ms SPDIF RTL vs. 4.208ms "ASIO" RTL)?

If you need/want to measure analog RTL more accurately (and see how stable it is), you can use an approach like that nicely explained at http://wiki.cockos.com/wiki/index.ph...erface_Latency.

My AIDIOFIRE4 (6ms analog RTL at 48k & 64 sample buffer) has 79 samples DML, and my Studio Capture (4.9ms analog RTL at 48k & 32 sample buffer) has 81.

Last edited by AmackG; 4th January 2017 at 01:40 AM.. Reason: Finish
Old 4th January 2017
  #1163
Lives for gear
 
TAFKAT's Avatar
 
🎧 15 years
I know a few have been asking for the Focusrite results which had been deferred after their 2.1.2 driver took a detour of sorts , so I'll post up the results and a quick overview now and then post up the larger report when I have completed the rest of the testing on the other interfaces.



O.K, what exactly are we looking at here. I'll explain in detail below but first I do need to cover the reasoning of why I deferred posting the results.

I first tested the initial Version 2.00 driver , posted the results and summary only to be informed that an updated driver had been released the day prior that I had missed. To be thorough I retested the updated driver which had introduced some performance issues , so I pulled the results, made contact and worked with Focusrite QA to resolve the issue that I had encountered. I do have to commend the Focusrite reps for being open enough to hear me out, acknowledge the problem and then work to remedy the issues I reported. A welcome change to experiences I have had in the past with other manufacturers.

With that out of the way, some will be asking why there are 2 sets of results.

The Focusrite Control Panel has buffer settings starting at 16 samples , which on a USB interface is essentially impossible to achieve due to the limitations of the USB protocol. On even closer inspection you will notice that the actual delivered latency of the listed settings are around double what other more conventional settings would be delivering i.e, most interfaces for a 256 buffer setting would have respective I/O latency around 6.5-7.5ms , 512 would be around 12.5-13.5ms , however going by the Focusrites Standard Panel Settings , 256 has 12.5ms , 512 has 24ms , essentially double.

Thing is performance at the respective delivered latencies was actually quite good, so to closer approximate the results comparatively against other interfaces using similar respective I/O latencies, I shifted the results down one position and have listed an alternate and IMO, more accurate comparative chart.

I have spoken to Focusrite QA about simply relabeling the panel settings to better reflect the respective latencies , and I have been told its under consideration.

The performance of the 2.1.5 driver is pretty much back to the original driver , respective latencies are up a tiny bit , but the performance is very smooth. What had happened at 2.1.2 was that most of the latency values had been driven down further than the original release, but it had impacted severely with the overall performance of the driver , so it was scaled back and the performance has been returned.

This highlights what I have noted recently, that updated drivers do not automatically mean better performance in some instances.

Old 4th January 2017 | Show parent
  #1164
Lives for gear
 
Clockwise's Avatar
 
🎧 5 years
Quote:
Originally Posted by AmackG ➡️
This stuff is pretty new to me, so I'm sorry if these are stupid questions. Are stereo ASIO in and out the same as ADAT in and out? Do they undergo less processing in the interface than SPDIF (to account for your 4.464ms SPDIF RTL vs. 4.208ms "ASIO" RTL)?

If you need/want to measure analog RTL more accurately (and see how stable it is), you can use an approach like that nicely explained at How to Compensate for Interface Latency - CockosWiki.

My AIDIOFIRE4 (6ms analog RTL at 48k & 64 sample buffer) has 79 samples DML, and my Studio Capture (4.9ms analog RTL at 48k & 32 sample buffer) has 81.
Well, those desktop E-MU interfaces operate on this software called Patchmix which is a virtual mixer. It allows you to route physical inputs (mic/line combo, stereo phono, S/PDIF and ADAT) and ASIO outs to physical outs (analogue or digital) or ASIO ins. It's a bit hard to explain without showing you the software in action, I suppose you could compare it to something like UAD Console (as Apollos are designed by former E-MU guys hence based on E-MU systems).

Anyways, this is how things went when measuring the RTL with analogue, digital and ASIO in/out.

Analogue... Connect the Line out 1/2 to Line in 1/2, tick the appropriate boxes in the RTL Utility and measure the RTL.

Digital... Connect the S/PDIF out to S/PDIF in, and do the same as above.

ASIO... Inside the Patchmix software, route ASIO out 1/2 to ASIO in 1/2, and do the same.

So yeah, Digital I/O and ASIO I/O are different as digitals are routed externally (with an RCA cable connected to S/PDIF I/O) whereas ASIOs are routed internally (within the Patchmix software). Does that make sense?
Old 4th January 2017
  #1165
Gear Head
 
🎧 10 years
Thank you so much Vin for posting the focusrite results.It seems for me right now the only way is rme usb or an older focusrite saffire firewire product.Thanks again Vin
Old 4th January 2017 | Show parent
  #1166
Lives for gear
 
TAFKAT's Avatar
 
🎧 15 years
Quote:
Originally Posted by Clockwise ➡️

Anyways, this is how things went when measuring the RTL with analogue, digital and ASIO in/out.

Analogue... Connect the Line out 1/2 to Line in 1/2, tick the appropriate boxes in the RTL Utility and measure the RTL.

Digital... Connect the S/PDIF out to S/PDIF in, and do the same as above.

ASIO... Inside the Patchmix software, route ASIO out 1/2 to ASIO in 1/2, and do the same.
?

You are over complicating and confusing this.

RTL via the Utility is the measurement of the Analog (or Digital ) path via the ASIO driver at respective latencies. If you eliminate the driver via ASIO/Hardware Direct Monitoring , then the ASIO driver component does not come into play at all. That is not the RTL that is being referred to in these reports, that is simply the amount of combined latency of the AD/DA when direct monitoring an analog source.

Old 4th January 2017 | Show parent
  #1167
Gear Nut
 
🎧 5 years
Quote:
Originally Posted by Clockwise ➡️
Well, those desktop E-MU interfaces operate on this software called Patchmix which is a virtual mixer. It allows you to route physical inputs (mic/line combo, stereo phono, S/PDIF and ADAT) and ASIO outs to physical outs (analogue or digital) or ASIO ins. It's a bit hard to explain without showing you the software in action, I suppose you could compare it to something like UAD Console (as Apollos are designed by former E-MU guys hence based on E-MU systems).

Anyways, this is how things went when measuring the RTL with analogue, digital and ASIO in/out.

Analogue... Connect the Line out 1/2 to Line in 1/2, tick the appropriate boxes in the RTL Utility and measure the RTL.

Digital... Connect the S/PDIF out to S/PDIF in, and do the same as above.

ASIO... Inside the Patchmix software, route ASIO out 1/2 to ASIO in 1/2, and do the same.

So yeah, Digital I/O and ASIO I/O are different as digitals are routed externally (with an RCA cable connected to S/PDIF I/O) whereas ASIOs are routed internally (within the Patchmix software). Does that make sense?
It does - thanks! None of my interfaces have direct ASIO loopback capabilities

OOPs - it turns out that Roland Studio Captures do have "DAW Monitor" capability (including the "DAW input") after all. Both input and output level controls have an effect but that doesn't seem to affect latency. It seems a little messed up though since both DAW Monitor channels appear to be identical (showing the sum of their input channels).

Last edited by AmackG; 7th January 2017 at 05:24 AM.. Reason: Correct
Old 5th January 2017 | Show parent
  #1168
Gear Nut
 
🎧 5 years
Quote:
Originally Posted by TAFKAT ➡️
I know a few have been asking for the Focusrite results which had been deferred after their 2.1.2 driver took a detour of sorts , so I'll post up the results and a quick overview now and then post up the larger report when I have completed the rest of the testing on the other interfaces.



O.K, what exactly are we looking at here. I'll explain in detail below but first I do need to cover the reasoning of why I deferred posting the results.

I first tested the initial Version 2.00 driver , posted the results and summary only to be informed that an updated driver had been released the day prior that I had missed. To be thorough I retested the updated driver which had introduced some performance issues , so I pulled the results, made contact and worked with Focusrite QA to resolve the issue that I had encountered. I do have to commend the Focusrite reps for being open enough to hear me out, acknowledge the problem and then work to remedy the issues I reported. A welcome change to experiences I have had in the past with other manufacturers.

With that out of the way, some will be asking why there are 2 sets of results.

The Focusrite Control Panel has buffer settings starting at 16 samples , which on a USB interface is essentially impossible to achieve due to the limitations of the USB protocol. On even closer inspection you will notice that the actual delivered latency of the listed settings are around double what other more conventional settings would be delivering i.e, most interfaces for a 256 buffer setting would have respective I/O latency around 6.5-7.5ms , 512 would be around 12.5-13.5ms , however going by the Focusrites Standard Panel Settings , 256 has 12.5ms , 512 has 24ms , essentially double.

Thing is performance at the respective delivered latencies was actually quite good, so to closer approximate the results comparatively against other interfaces using similar respective I/O latencies, I shifted the results down one position and have listed an alternate and IMO, more accurate comparative chart.

I have spoken to Focusrite QA about simply relabeling the panel settings to better reflect the respective latencies , and I have been told its under consideration.

The performance of the 2.1.5 driver is pretty much back to the original driver , respective latencies are up a tiny bit , but the performance is very smooth. What had happened at 2.1.2 was that most of the latency values had been driven down further than the original release, but it had impacted severely with the overall performance of the driver , so it was scaled back and the performance has been returned.

This highlights what I have noted recently, that updated drivers do not automatically mean better performance in some instances.


I noticed that you were using windows 7.. what about the Scarlett 18i20 ??? what about windows 10???? sorry not trying to be pushy I am just trying to gather as much info as possible before I drop a ton of money down... I want some thing that works LOL
Old 5th January 2017 | Show parent
  #1169
Lives for gear
 
TAFKAT's Avatar
 
🎧 15 years
Quote:
Originally Posted by bogy1 ➡️
I noticed that you were using windows 7.. what about the Scarlett 18i20 ??? what about windows 10???? sorry not trying to be pushy I am just trying to gather as much info as possible before I drop a ton of money down... I want some thing that works LOL
The USB driver is universal for all of the Scarlett Gen 2 interfaces with DSP , performance will be identical between the 6i6 and 18i20

re Windows 7, all testing will remain on Windows 7 where possible to maintain consistency with the database , also, I have not seen anything to indicate that there is a quantifiable difference between Windows 7 and Windows 10 in regards to Audio Performance.


Last edited by TAFKAT; 5th January 2017 at 04:44 AM..
Old 5th January 2017 | Show parent
  #1170
Lives for gear
 
Clockwise's Avatar
 
🎧 5 years
Quote:
Originally Posted by TAFKAT ➡️
?

You are over complicating and confusing this.

RTL via the Utility is the measurement of the Analog (or Digital ) path via the ASIO driver at respective latencies. If you eliminate the driver via ASIO/Hardware Direct Monitoring , then the ASIO driver component does not come into play at all. That is not the RTL that is being referred to in these reports, that is simply the amount of combined latency of the AD/DA when direct monitoring an analog source.

Umm, I suspect you would need a hands-on experience with Patchmix to understand the routing I'm referring to. I'll try and see if I could post a snapshot of the Patchmix settings, or is it rather OT?
📝 Reply

Similar Threads

Thread / Thread Starter Replies / Views Last Post
replies: 2521 views: 455004
Avatar for Nickerz
Nickerz 1 hour ago
replies: 61 views: 13041
Avatar for Transistor
Transistor 21st February 2015
replies: 486 views: 132825
Avatar for blackcom
blackcom 14th September 2020
replies: 193 views: 25773
Avatar for band user
band user 10th July 2015
Post Reply

Welcome to the Gearspace Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…

Forum Jump
Forum Jump