Search form

[ef37a]

Used the latest drivers and firmware updates? Or are we both confused now?

Dave.

I'm sure he has - the guy was asking for an opinion, there's nothing to be confused about :)

Oooo! Old, meds, easily done I assure you!

Dave.

[TAFKAT]

Thanks - just wondering, since the UR28M is listed as having driver 1.1.1 on the page you linked to, would those results not necessarily be applicable to the latest driver?

Any driver 1.1.1 or above will have the improved performance.

One question on your last column if I could - some of the RTL columns have a double " ** ", with the comment "RTL calculated via utility". What does that mean, as opposed to RTL being calculated in a different fashion?

Some of the results are from pre the RTL Utility, those sans the RTL calculation also include the AD/DA in the I/O values , so the measured RTL would be very close , but I will amend what units I still have access to on the next update.

I guess in a practical sense, for my UR28M - the numbers in your column are greater than my old Delta 44 card reported in its control panel ... 10 years ago! Do the RTL numbers in your last column reflect the "real-world" latency, regardless of what the UR28M's control panel reports?

Can't remember that far back, sorry. The Delta may have been reporting Nominal figures back then, if so, they will have no correlation to what was actually delivered.

And if I'm recording/tracking using "direct monitoring" does the actual latency become unimportant? (Or maybe it is still very important? ... For example if another application like UAD-2 looks to Cubase's Control Panel to perform latency compensation, but it is reported by Cubase incorrectly as determined by your testing, and so things go awry?)

Direct monitoring is AD/DA + DSP/FPGA , so if you are recording dry, buffers are unimportant to that recording environment, but you cannot monitor FX. If there is a large variance between what is reported and actually delivered, it can interfere with Plugin Delay Compensation , most DAW's have a way of dialling in th values of the AD/DA if need be, but if there are hidden buffers not being reported , its more difficult. Most don't bother with the AD/DA values as they pretty small.

V.C

[alexis]

Thanks - just wondering, since the UR28M is listed as having driver 1.1.1 on the page you linked to, would those results not necessarily be applicable to the latest driver?

Any driver 1.1.1 or above will have the improved performance.

One question on your last column if I could - some of the RTL columns have a double " ** ", with the comment "RTL calculated via utility". What does that mean, as opposed to RTL being calculated in a different fashion?

Some of the results are from pre the RTL Utility, those sans the RTL calculation also include the AD/DA in the I/O values , so the measured RTL would be very close , but I will amend what units I still have access to on the next update.

I guess in a practical sense, for my UR28M - the numbers in your column are greater than my old Delta 44 card reported in its control panel ... 10 years ago! Do the RTL numbers in your last column reflect the "real-world" latency, regardless of what the UR28M's control panel reports?

Can't remember that far back, sorry. The Delta may have been reporting Nominal figures back then, if so, they will have no correlation to what was actually delivered.

And if I'm recording/tracking using "direct monitoring" does the actual latency become unimportant? (Or maybe it is still very important? ... For example if another application like UAD-2 looks to Cubase's Control Panel to perform latency compensation, but it is reported by Cubase incorrectly as determined by your testing, and so things go awry?)

Direct monitoring is AD/DA + DSP/FPGA , so if you are recording dry, buffers are unimportant to that recording environment, but you cannot monitor FX. If there is a large variance between what is reported and actually delivered, it can interfere with Plugin Delay Compensation , most DAW's have a way of dialling in th values of the AD/DA if need be, but if there are hidden buffers not being reported , its more difficult. Most don't bother with the AD/DA values as they pretty small.

V.C

Thank you,Vin, for your time in responding!

With the caveat of not knowing whether Cubase's PDC is getting accurate number from the UR28M, I think I'm in OK shape. I record zero latency/dry (actually the interface has a reverb it applies for tracking with zero latency), so the buffers aren't that important in that respect.

And I'm going to guess that since the UR28M is a Steinberg unit, it does communicate well with Cubase in terms of reporting actual latencies for PDC calculation purposes. But I won't bet the farm on it ... :)

Thanks again, TAFKAT!

[Goddard]

Came across another audio interface RTL database which may be of interest.

8-)

[robinv]

That's a nice article - the only thing missing is any kind of relative performance testing. Two interfaces with the same RTL may have vastly difference performances in terms of tracks, effects and VSTi's it can cope with at that latency. It would be cool if he could show that..... although, as we know, that's a ton of work :)

[robinv]

Hey, finally Focusrite pull their socks up
http://uk.focusrite.com/clarett-range#

[Neo-Classical Guitar Man]

Very nice so long as it works without any issues. The only thing for me would be the expense of moving to hardware that supports the Thunderbolt format.

[TAFKAT]

Just blowing the some cobwebs to let you guys know I am still alive and kicking on this project :-)

I ran the Steinberg UR44 thru its paces over the last few days , performance was similar to that of the earlier UR28M I had tested and listed in the database with the version 1.* driver - the Version 2 driver being a little down actually.

I'll post up some updates shortly once I have a few more of the newer interfaces tested.

V.C

[Martin Walker]

Just blowing the some cobwebs to let you guys know I am still alive and kicking on this project :-)

I'll hold off from nailing on the top of that coffin then Vin


Martin

[tea for two]

http://youtu.be/ojnnP_GXNaM

Lego 20min55 made me smile :) 8-)

Nick Park stylee

[robinv]

http://youtu.be/ojnnP_GXNaM

Lego 20min55 made me smile :) 8-)

Nick Park stylee

I thank you - years in the making.

[tea for two]

Observation :

my i5 & Novation XStation audio midi kb synth.
One softsynth one track: performing live touch screen : Alchemy Remix Pads.
Fast trills Piano, fast rolls Tabla

ASIO4ALL : 44.1- 48kHz

512samples 11ms = 30.7ms Round Trip Latency, 14.3ms output latency.
is as instantaneous (to my ears headphones) as
64samples 1.5ms =10.3ms Round Trip Latency, 4.2ms output latency
as is 
1024samples 23.2ms = 53.9ms Round Trip Latency, 25.9ms output latency.


Currently comfortable 768samples 17.4ms = 42.3ms 1864samples Round Trip Latency, 20.1ms output latency.


(No optimisations Windows 7 Pro 64bit. Everything standard, just WiFi turned off).

[TAFKAT]

Update to kick off 2016.

A few additions, some typos amended , details below charts.





Added :

Roland Studio Capture : This is a series of interfaces that I have wanted to qualify for a while , and I finally managed to get one across the bench. I am not sure whether the drivers are universal across the range - i.e Quad Capture / Octo Capture , but this being the latest I would expect the drivers to be the most up to date.

There has been a fair bit of discussion of not only this particular interface but also the others in the Capture range re Rolands claims of superior latency performance. In the past there has been some confusion navigating the low latency mode , which was at one point labelled Reduce CPU Load, which many thought was the opposite of what it actually did , but its clearly marked now, and was duly engaged.

Figures are for the Low Latency Mode , so I was very surprised to see the double buffering on playback , which is not overly apparent at the lower latency settings, but become significantly more apparent as the buffers are ramped up.

Playback buffers are some of the largest I have seen on any of the tested interfaces, which brought about some interesting results across the benchmarks , which are based on playback buffer size mostly.

Benchmark results on the surface look very good at the respective latencies in comparison to the reference and most other interfaces, what is not evident unless highlighted is that the results are achieved in some cases at double the actual playback latency per respective buffer setting. The leveller is the RTL value , but the unit still achieves a higher rating due to the faux 032 setting , IMO.

The double buffering on playback forces you to work at a lower buffer setting when requiring comfortable real time playing of VI's , and those requiring tight RTL for Guitar Amp Sims and monitoring with FX will need to be mindful that anything above the 064 buffer setting ramps the RTL quite substantially.

Steinberg UR44 : The Steinberg UR44 delivered performance similar to the UR28 that had been tested previously , a touch higher I/O and RTL on the lowest buffer setting. Unit reports true I/O latency values instead of hiding behind a placebo of not reporting AD/DA and hidden buffers that seems more and more common lately. LLP is quite good but needs to be balanced with the higher I/O and RTL.

Presonus Studio 192 : There has been quite a bit of interest in this unit since its announcement, mostly due to the USB3 connectivity and what that brings to the table in regards to LLP. I had noted earlier in discussions that it will depend on the driver/controller , USB3 as a protocol will not deliver better LLP, simply more available bandwidth for higher I/O. So what was the end result, in a nutshell, and as I has expected, the unit performs identically under USB2/3.

I spent a lot of time with this unit , too much actually, as there was a significant variance between reported and delivered latency which I have detailed over at the dedicated Studio 192 thread at another forum and I won't bore you with here as I am distancing myself away from the ongoing soap opera.

I/O and RTL is higher than expected , driver performance and efficiency is essentially the same as all the other interfaces using the same base off the shelf OEM driver - VSL, Audient , etc, any time you see the reported value of 2.449 at 064 , 3.900 at 128 , etc, it is the same off the shelf driver, the drivers are average performers for those requiring better LLP.

I navigated a few other curves - the unit initially would not install on Windows 7 due to a driver signing issue ( I read about the same issue on the Antelope's recent drivers as well, not overly surprising , its the same off the shelf driver ). I did resolve that , it required a recent security patch of Windows , unfortunately I can't confirm which exact security patch is required , so for those that prefer to lock down their working configurations, tread carefully when updating the OS installation.

Tested but not added.

Antelope Orion 32 : I didn't have the facility ( appropriate cabling ) to measure and report the measured RTL's but the Reported Latency values are identical to a number of the other interfaces tested previously ( Audient iD22/Presonus AudioBox 44 VSL, Studio 192 ) which confirms the driver is the standard 3rd party OEM driver I mentioned earlier. AD/DA is not reported, so measured RTL will depend on the respective AD/DA latency, and any additional hidden delays associated with the FPGA/Controller

Performance wise was as expected and right in line with the previous units tested with the same respective OEM driver, i.e - Average , so despite all of the hype about proprietary controllers, if in fact they are using one, performance is no better than the off the shelf options some others are using.

I encountered some further curves in regards to reliable connectivity, which has been widely reported on the dedicated thread here across both PC and MAC.

Now just to finish off and give everyone a heads up on further testing and the minefields that are required to be navigated. First and foremost , there are not many instances where a unit is sent to me from the manufacturers for testing, its either I purchase the unit or I have a clients unit to test and qualify on a system build. So as much as I would like to test all of the new interfaces appearing on the market, there are times where it is very difficult to get in front of one as I suspect some manufacturers are not overly interested in me placing the units under the microscope.

Its is getting harder to balance, relationships have been strained and I need to be mindful of remaining as objective and detached when providing a summary of the units LLP, because it is really up to the individual and their respective requirements to decide what is acceptable in regards to latency/performance.

To be honest its feeling like ground hog day to me ( which I have mentioned before ) , the performance of newer USB2 interfaces has been in a holding pattern for years and I can't see it changing. Using USB2/3 RME will remain the only manufacturer that can confidently go toe to toe with the better performing devices IMO, all others are dependent on the same OEM off the shelf driver which I seriously doubt will see any further development.

Thunderbolt is the next wave , performance again will be dependent 100% on the drivers /controllers , not simply because its a faster protocol. I do have a system to be able to test TB units when available but it is not the core reference system, so I will need to do some extra work to get comparative performance numbers , but it is on the list of things to do in future.

Peace and Out

Vin Curigliano

[robinv]

Nice work - as always :)
I think we all appreciate what you do and the time you put into this never ending cycle, but, you know, look after yourself.

Cheers
Robin

[Pete Kaine]

Cheers for the update Vin.

Glad to see the Steinberg / Roland drivers have come on somewhat over the years. When I first handled them a few years back, I had to have chats with teams from both firms about the perfomance on some of the units. Your testing show that they look to be a lot more capable these days, glad they've done the work on them.

From our testing, I'd suggest the Zoom USB3 units are worth an examination if one drifts past you as the controller in those is great under USB3 and handles almost as well under USB2 (proving your point made above, about USB3 itself not automatically being anything special), although on older chipsets they've been a little fussy in the usage situations I've had, so I'm not overly confident you'd get one up and running smoothly on the X58 rig.

Might have to try that myself in fact, if I can dig the old benchbox out of the storage room!

[Martin Walker]

Thanks for the latest updates Vin - your name should already be at the top of the Interface Hall Of Fame, but if not I'll propose you immediately


Martin

[TAFKAT]

Cheers Robin, Pete, Martin :-)


@ Pete,

Re the Zoom, do the drivers give a clue on what they are using ?

Is it the usual 2.449/3.900 reported values at lowest Safety Buffer ?

Re the USB3/2 aspect, the Presonus 192 worked equally across USB3/2. As you noted, 3rd party USB3 on some of the earlier boards is a crapshoot , but the max I/O expandability of the unit still wouldn't max a USB2.0 controller , so its not an issue running it on earlier system in regards to connectivity/performance. USB3 doesn't even come into play at 24 I/O ( 8 Analog , 2 x ADAT at Max 48K ). Same applies for the Zoom with even less max I/O capability.

V:

[Pete Kaine]

Ahhh, completely agree mate, I'm just saying the Zoom can be a bit fussy when hooked up to none Intel controllers.

I don't have one near by at the moment, but I can throw one through some tests next time one appears. Only benches I've got was the standard loopback times:


..... 44.1 / 48.0


32 = 4.007 / 3.67
64 = 5.456 / 5.10
128 = 8.360 / 7.677
256 = 14.165 13.010

Add .80 to each one and your in the ballpark of the USB2 result.

[TAFKAT]

Hey Pete,

Thanks for that.

So there was a measurable difference between USB3/2 in delivered latency ?

Thats interesting, it must place the driver in a different bus (safe) buffering mode.

I'll be interested to see some more details on the unit when you get a chance.

V:

[Pete Kaine]

Yes, and from what I can recall it was fairly constant across the buffer sizes, so you may well be right with that.