Audio Interface - Low Latency Performance Data Base :

[Patrice Brousseau]

Right then, I'll throw a quick comment into this thread, althrough I'll need a chat with Vin before we get them up properly.

The Octo came out at a score of 5.3.

RTL:
7.6 @ 32
12.09 @ 64
20.75 @ 256

So perfectly usable at 32 althrough real time monitoring might become a little questionable at 64 and above.

With RTL Oblique util:

7.659ms at 64 [email]samples@44.1kHz.[/email] This is with 1.5 drivers, option "Reduce CPU load" ticked (without this option, the figures goes around 9.5ms).

48 buffers: 6.4ms

On a MacBookPro, Win7 SP1 x64 in Bootcamp.

I repeat, if you don't tick "Reduce CPU load", the figures goes higher. Maybe also that the 1.50 driver is better optimized in this regard compared to the new 1.51.

Just to be sure, I've also ran a loopback test inside Reaper and the RTL figures are the same.

**As a sidenote, AU Lab (an utility, AU and VST Host under OSX) reports exactly the figures, confirmed by loopback test.

"AU Lab : hardware input : 136 samples safety offset : 22 samples
hardware output : 4 samples safety offset : 22 samples"
Obviously, you add 64 in and 64 out and by calculating number of samples: 312 samples or 7.1ms. RTL figure is a bit lower in CoreAudio but probably that Reaper won't be unable to sustain the same loads as under Win7 x64.

Patrice

BTW, the interface could go as low as 32 samples but I don't know the real efficiency with this low latency...

[Patrice Brousseau]

BTW,

Echo Mia, drivers 6.08 wrapped under ASIO4ALL 2.7:

On XP 32 bits: 64 [email]buffers@44.1[/email] kHz, 6.1 ms RTL, not bad.

Edirol FA-66 also wrapped under ASIO4ALL: 64 [email]buffers@44.1[/email] kHz, 8.8ms RTL. Usable but not impressive.

Now, for those asking why using ASIO4ALL? With native Echo Asio drivers, RTL is 5.7ms but the setting is almost unusable as it "crackle-pops" easily.

The Edirol: lowest Asio buffer, 88 giving 10.something RTL... Forget software monitoring!

And why XP32 on my old (Q6600, 4 Gb's RAM) desktop? It performs flawlessly as low as 64 buffers without worrying about instabilities or drop-out. Just make music...

I would like for sure to add a streamlined Win7 x64 DAW boot but so far, the Edirol and Echo results under my standard (Web, Office) boot are less than stellar (crackles, midi playing sluggish with just 128 buffers. This was with all unnecessary services and processes disabled, classic theme, latest drivers...

Patrice

[TAFKAT]

Hey,

Its been a while but I have updated the database , added a few , removed a few and will give a quick review of the new entries.




Additions :

ESI Julia XTe : What a pleasant surprise packet this little card turned out to be after the mixed result of the earlier MAYA44e card. Lower RTL than the RME base reference for the working latencies , respectable performance across the 3 benchmarks placed it well in the upper registers of the LLP table. Its still not without a few quirks, one being the reported latency is nominal for In/Out, so we really aren't entirely sure what the real deal is there. the latency variance is between reported and calculated is 54-69 samples so that could be combination of the AD/DA and some added buffers, but no way to really check 100%..

Presonus Firestudio Mobile : Another one that was a very pleasant and welcome surprise with the new Version 4.0 driver from TC Applied. So someone was listening, in short a great performer now only bettered by the RME's. Very solid performance across all benchmarks and working latencies. The version 4 driver is a unified driver across all the range, so the improved performance is valid for the larger Firestudio Project and the Digital Mixers as well.

Focusrite Saffire Pro 24 : Ditto the above , using the same TC applied supplied Version 4.0 driver as Presonus. Performance across the benchmarks was identical to the presonus, the RTL was a little better so it achieved a higher RTL. Again this performance is valid across all the Focusrite FW range.

MOTU 828 Mk3 Hybrid : Where do I start , the unit is a FW400 / USB2 Hybrid interface that MOTU have not had the wisdom to even supply a FW800 to FW400 cable with , very obvious that the target market is not Windows , but lets not get to caught up with that. The unit is based on a new ArchWave controller and uses a unified driver install for both FW/USB2 which reported identical In/Out values for both FW and USB2 to Cubase which immediately threw up a bit of a flag. On using the RTL Utility the values were measurably different so already we have some grey area to navigate. The RTL Utility was also reporting an error in the calculation because the value was over 50% different to what was being reported by the driver , enter hidden buffers , not to mention the double buffering on playback to round off the less then stellar RTL values.

All that aside, how did it perform. FW performed almost equivalent to the previous non Hybrid , but not as good in RTL or benchmark results , the USB when I could arm-wrestle some consistency , performed measurably worse than the FW. Overall, pretty average.

Mackie Onyx 1640i : Heres one I had been sitting on for a while as I didn't have the measured RTL values and the reported nominal values were, hmmm, very optimistic. I finally had the opportunity to get in front of one again to do the RTL calculations. Wow, in short the settings values have absolutely no correlation to what is delivered and even more concerning was I could not get a consistent result from the RTL utility, with the value swing around up to 80 samples at a time. Check out the cart for the actual delivered RTL , I have no idea how the DAW's could possible compensate for that amount of variance , absolutely unworkable IMO.

Removed :

Presonus Studio Live/ Focusrite Saffire 56 : With the new version 4 unified driver I will update the individual units when I get the opportunity , but for now the new enties will give a good indication of where they sit in the LLP table.

MOTU 828 Mk3 FW : No longer current, tables updated to the new Mk3 Hybrid.

Tested but not included :

Focusrite Scarlett 18i6 : I tried very hard to get a result for this interface but it threw up a few challenges. First off the buffers are set to ms so I didn't have the required range of buffer settings, they also have absolutely no correlation to what is delivered. The reported values show double buffering on input, triple on playback and to top it off, the calculated RTL was lower than than that reported by the driver. If allowed a bit of grey to allow the 2 lower buffer settings of 1ms/2ms to replace 032/064 I came up with an overall LLP in the low 4's , RTL's ranged from 6.858 at the supposed 1ms value all the way to 61.997 at the supposed 12ms. That should give everyone enough of an idea of where the interface sits in the greater scheme.

I said earlier that I was going to comment in detail on Hughs responses re RedNet but on further consideration I am going to reserve comment until I have the opportunity to test it myself. There is just so much grey in the commentary regarding what the actual latency values are being reported ( RTL or Direct Monitoring ) that it really needs to be 100% clarified, which cannot be accomplished without being in front of the units again. There is also the question of how it actually performs at the respective working latencies as well as the so called intended market , but I'll cover that at the appropriate time if/when I can get a chance to test the units.

Peace

Vin Curigliano

[Goddard]

Good on you, Vin! Thanks for the update!

Wrt the ESI Julia XTe, wondering if the contemporary Maya44 XTe (updated version of Maya44e) performs similarly?

As you've not included Scan's Roland Octa test numbers (due to test system differences?), let's hope that Martin or perhaps Craig A. might persuade Roland to send some interfaces your way.

And while you're waiting on Rednet, keep an eye out for AVB-capable interfaces to materialize (Prism Lyra2?), as Intel are already offering an AVB-capable NIC.

[TAFKAT]

Hey G,

Not sure about the ESI 44XTe , the driver version is slightly different but it could well be better as its a family of driver versions closer to the Julia XTe.

Re the Roland, I have given up asking for a test unit, Roland are obviously not interested .

Re RedNet and beyond, hmmm, lets see what it actually delivers , I may also have a chance of getting in front of an Antelope Orion 32 with its so called uber proprietary USB2 controller, so some interesting days ahead I suspect. I hope the reports of the OSX performance/stability isn't a reflection of the Windows driver.

V.

[Goddard]

Hey V, I hear ya.

Meanwhile, also on the horizon is external PCIe, with a MADI interface having both e-PCIe and USB3 connectivity supposedly coming soon from RME and e-PCIe host cards already available, along with the possibility of networking systems together over e-PCIe.

And, due to the way Apple and especially Intel have been keeping a rein on TB, I've heard it's only a matter of time before laptops and desktops with e-PCIe ports onboard finally start appearing, so things may get real interesting real soon.

[TAFKAT]

Hey G,

ePCIe will be interesting to watch , TB has been little more than an afterthought on Windows and I have serious doubts of it reaching a market level for it to be viable for many if not most on Windows.

Intel should have allowed the release of PCIe 4X only capability years ago , instead of locking it to the current spec. Most of us in the industry couldn't care less about the Displayport integration, especially on the desktop.

I think RME's latest move is hinting what they think of TB as a cross platform interconnectivity.

V.

[Lodious]

Can I ask a simple question? When you are talking about using the "TC applied supplied Version 4.0 Driver", is this something ordinary consumers can use, and if so, how would we get it? Do we have to wait for (for example) Focusrite to rollout an updated driver which uses it, or can it be downloaded from TC applied's website (I had a quick look and could not see it)?

Thanks,

[Pete Kaine]

You need to wait until the respective companies roll it into an update for you. I believe that Focusrite managed this with the last build of Mixcontrol from what I remember.

[Lodious]

Thanks for the info Pete.

[Goddard]

Re the Roland, I have given up asking for a test unit, Roland are obviously not interested .

Perhaps Roland should seriously consider their participation now in view of Sam Inglis' assessment of the touted "industry-leading low latency USB performance" of their newest Studio Capture interface in the current issue of SOS.

Kudos to Sam and SOS for telling it like it really is (er, isn't?)!

[TAFKAT]

That review totally slipped under my radar , tho I had spoken to Sam during his testing phase while doing the review.

+1 Kudos to Sam, this is what we need in regards to product reviews to not only give the end users the real situation in regards to delivered performance, but also remind the manufacturers that they can be held accountable when the performance doesn't match their spin.

I suspect now that any chance of getting a test unit in my hands would be even further away

V.C

[Goddard]

Something is nagging at me about all this. Roland certainly know how to design USB interfaces (iirc they were the first out with USB1 and USB2 interfaces) and have the resources and expertise for firmware and driver development.

[TAFKAT]

It comes down to the USB controllers / drivers Roland utilise G, I would be very surprised they have developed their own.

I suspect its the same XMOS USB controller all of the other manufacturers utilise, so its down to who has developed the drivers.

V.C

[Goddard]

It comes down to the USB controllers / drivers Roland utilise G, I would be very surprised they have developed their own.

I suspect its the same XMOS USB controller all of the other manufacturers utilise, so its down to who has developed the drivers.

V.C

Sorry to disagree V, but I'm pretty certain you are wrong about Roland buying-in their USB controller and not doing their own driver development.

[Goddard]

(Too late to edit earlier post)

Just to be clear when talking about "USB controllers", a distinction should probably be made between a "USB controller" (more properly, a "USB interface controller") as the component handling stream interfacing between the USB and the core internal digital components in an audio/MIDI interface such as ADC and DAC (codecs) and mixer/fx DSP logic, and a "USB audio/MIDI microcontroller" like the XMOS or Archwave chips (or, in the case of FW interfaces, TC-AT DICE family chips) which integrates a USB (or FW) interface controller (or interfacing links for an external USB interface controller) plus additionally includes core logic (such as an embededded RISC core(S)) and related interfaces and functionalities for the audio/MIDI interface.

My understanding and experience is that while Roland may utilize bought-in USB interface controllers such as from Renesas(NEC), TI, etc., they do develop and produce their own in-house "audio/MIDI microcontroller" logic and ASICs and drivers. And I'm fairly certain the same applies for Yamaha/Steinberg gear as well.

[TAFKAT]

G,

Its all inconsequential whether Roland use 3rd party or do in house, IMO, its all in the delivery or lack there of. If we can get confirmation either way, that will be of interest to some, but personally I couldn't care less to be honest.

Everyone seems to think they can design a better mouse trap when it comes to USB2, Antelope are the latest making outlandish claims about the superiority of their proprietary USB2 controller in regards to low latency performance. Have they delivered ? Who knows, even tho the unit was reviewed recently in SOS with a reported 7.82 RTL @ 64 / 44.1 , ( RME UFX is 5.056 at the same settings ) there is absolutely no indication of how it actually performed at that latency. Reading in at some ongoing threads it varies from being a basket case to a giddy shill infested game changer. I am betting its somewhere in between , but until I get in front of one, I'll reserve comment.

IMO - The only company who has developed and delivered USB2 performance that is comparable to the better FW units is RME !

V.C

[Pete Kaine]

Well I was going to try and keep away from this, but seeing as Vin's being called out and Sam is being questioned...

Perhaps Roland should seriously consider their participation now in view of Sam Inglis' assessment of the touted "industry-leading low latency USB performance" of their newest Studio Capture interface in the current issue of SOS.

Kudos to Sam and SOS for telling it like it really is (er, isn't?)!

Which issue no. is that exactly, I don't see it in the one in front of me and I'd really like to read it right now!

Something is nagging at me about all this. Roland certainly know how to design USB interfaces (iirc they were the first out with USB1 and USB2 interfaces) and have the resources and expertise for firmware and driver development.

I'd contest every statement you made in that sentence. Their drivers on everything I've had my hands on have under performed to the point of being unusable. I've an open case that's been going on for 3/4 months now where their Japan support has buck passed and failed to resolve it time after time.

Uk support is superb, but if you hit a problem that requires Japan to fix it, you can go whistle.

Its all inconsequential whether Roland use 3rd party or do in house, IMO, its all in the delivery or lack there of.

Exactly that.

[il Padrino]

Vince, is there any test that I can do on my Octa Capture that can help out here? If you message me any details, I'll see what I can do. I'm running Studio 64 bit on a Windows 7 64 OS, as well as Cubase Studio 5 64 bit. No worries if not!

[TAFKAT]

Pete,

Sam's review of the Roland Studio Capture is in the August 2013 Edition.

V.C

[Goddard]

Well I was going to try and keep away from this, but seeing as Vin's being called out and Sam is being questioned...

Pete, nobody's called Vin out here and Sam's review was certainly not being questioned (unless kudos have now become questions?). I was merely disagreeing about whether Roland develop in-house or buy-in.

You trying to stir up trouble or something?

Now, if you have a Roland AI about, you could pop the lid to see whether there's any XMOS or other 3rd party chip in there (sorry, my VS-20 is packed away at the mo else I'd oblige).

Perhaps Roland should seriously consider their participation now in view of Sam Inglis' assessment of the touted "industry-leading low latency USB performance" of their newest Studio Capture interface in the current issue of SOS.

Kudos to Sam and SOS for telling it like it really is (er, isn't?)!

Which issue no. is that exactly, I don't see it in the one in front of me and I'd really like to read it right now!

Sam's Studio Capture review

Something is nagging at me about all this. Roland certainly know how to design USB interfaces (iirc they were the first out with USB1 and USB2 interfaces) and have the resources and expertise for firmware and driver development.

I'd contest every statement you made in that sentence. Their drivers on everything I've had my hands on have under performed to the point of being unusable. I've an open case that's been going on for 3/4 months now where their Japan support has buck passed and failed to resolve it time after time.

Uk support is superb, but if you hit a problem that requires Japan to fix it, you can go whistle.

Hey, you calling me out?

Well, iirc they were very early out (if not the first ones out) with a USB1 interface (with onboard dsp fx to boot) back when, and also with a USB2 model. But that's not really relevant other than to suggest they did their own development rather than wait for a 3rd party solution to become available.

What's nagging at me is the feeling that Roland should still be capable of producing exemplary gear (and I've a good bit of their stuff boxed up for a move), and yet they apparently haven't. I certainly appreciate that they've kept up driver support for my long-OOP MIDI interface and not just for current production gear, but it's worrisome when development for high end gear like the VS-700 appears to have been dropped or at best put on the back burner and not kept pace with the Sonar platform for which it was designed.

Hearing of open cases going unresolved is troubling. Reminds me of the brouhaha with their Sonic Cell VST editor and VST3 a while back. Perhaps the folks in Hamamatsu are backlogged.

Its all inconsequential whether Roland use 3rd party or do in house, IMO, its all in the delivery or lack there of.

Exactly that.

Agreed, what bits get used is not really important, merely of passing academic interest as perhaps indicative of development expertise and resources. Don't really care about who made the pudding, only how tasty it proves to be...

[Pete Kaine]

Well I was going to try and keep away from this, but seeing as Vin's being called out and Sam is being questioned...

Pete, nobody's called Vin out here and Sam's review was certainly not being questioned (unless kudos have now become questions?). I was merely disagreeing about whether Roland develop in-house or buy-in.

You trying to stir up trouble or something?

Errr... not a whole lot..

Sorry, when I read " Something is nagging at me about all this. " I thought you were questioning the the testing or the results rather than where the controller came from. Miss-understood mate, carry on.

Now, if you have a Roland AI about, you could pop the lid to see whether there's any XMOS or other 3rd party chip in there (sorry, my VS-20 is packed away at the mo else I'd oblige).

Lattice FPGA with a AD Sharc sat next to it. It's not off the shelf in this instance.

Sam's Studio Capture review

Thanks, but I let me subscription lapse a few months ago and it appears someone has pikey'ed the office copy, so I'll have to try and track one down somewhere.

Hey, you calling me out?

With you... I honestly wouldn't dare!

Well, iirc they were very early out (if not the first ones out) with a USB1 interface (with onboard dsp fx to boot) back when, and also with a USB2 model. But that's not really relevant other than to suggest they did their own development rather than wait for a 3rd party solution to become available.

What's nagging at me is the feeling that Roland should still be capable of producing exemplary gear (and I've a good bit of their stuff boxed up for a move), and yet they apparently haven't. I certainly appreciate that they've kept up driver support for my long-OOP MIDI interface and not just for current production gear, but it's worrisome when development for high end gear like the VS-700 appears to have been dropped or at best put on the back burner and not kept pace with the Sonar platform for which it was designed.

As it happens this started off with a VS-700 issue and the fact it won't talk to the X79 chipset. That's the point I leant that they hadn't tested on anything newer than a X58 rig and expected it all just to work. It doesn't and the more testing I did the more problems surfaced. I'm seeing problems on the mobile chipset as well currently, it truely is shocking. Every avenue I looked down had people being told it's their configuration or some other piece of kit... i had to recreate various isses across 3 or 4 different generations of chipset before they'd consider listening. As for Sonar it picked up various bugs in X2A (and even X2) that don't appear to be getting resolved all that quickly, but at least in those cases the development team are working on them and really I'm happy about that. It's when they throw their hands up and go "yes it's broken, unlucky" I get annoyed.

Hearing of open cases going unresolved is troubling. Reminds me of the brouhaha with their Sonic Cell VST editor and VST3 a while back. Perhaps the folks in Hamamatsu are backlogged.

Do some reading on V-vocal if you want to see something that has never worked properly for a lot of people.

[Goddard]

As it happens this started off with a VS-700 issue and the fact it won't talk to the X79 chipset. That's the point I leant that they hadn't tested on anything newer than a X58 rig and expected it all just to work. It doesn't and the more testing I did the more problems surfaced. I'm seeing problems on the mobile chipset as well currently, it truely is shocking. Every avenue I looked down had people being told it's their configuration or some other piece of kit... i had to recreate various isses across 3 or 4 different generations of chipset before they'd consider listening. As for Sonar it picked up various bugs in X2A (and even X2) that don't appear to be getting resolved all that quickly, but at least in those cases the development team are working on them and really I'm happy about that. It's when they throw their hands up and go "yes it's broken, unlucky" I get annoyed.

May I presume you've been dealing with this issue as posted over in the CW forum?

If so, was a discrete USB controller card ever tried in lieu of the onboard USB ports?

The reasons I ask are because, firstly, the OP in that CW forum thread never responded about that, and, secondly, as you are no doubt aware, Intel rather radically changed their chipset USB controller topology when moving from their X58 platform (having a separate I/O controller hub (ICH 10) from which all USB connectivity was provided) to their X79 platform (in which the PCH now integrates all former ICH functions including USB), replacing their ICH's discrete UHCI/EHCI duality and port switching logic with a new PCH "rate matching hub" tier and no discrete UHCI. This change also affected Intel's 6-series (Sandy Bridge) and newer PCHs as used on desktop and mobile.

In this regard, note that the X79 USB controller's "rate matching hub" appears to software as an external USB hub (tier). Note also that Roland do state in the VS-700 manual (Memo on p.27):

The VS-700 may not be recognized correctly if you’re using a USB hub. In this case, connect it directly to a USB port on your computer.

Hmm...

It is rather shocking to hear that Roland hadn't tested on anything newer than an X58 rig (and thus wouldn't have become aware of issues arising on newer platforms), even if X58 had been their original development platform (along with Sonar 8.5).

I'm aware that a number of issues have been encountered using the VS-700 with the newer Sonar X1 and X2 versions. Dunno whether those are USB-related, although considering that all data transfer including all control messages between the VS-700 (and Octa) and PC are via USB, that's probably something to look into (along with all the USB-related errata detailed in Intel's X79 spec update).

Although it's odd that another poster in that CW forum thread had a very similar VS-700 and X79 setup using the same make mobo as the OP and reported things worked at low ASIO buffers.

Just to be clear (don't want you to think I'm calling you out!) I'm not coming to Roland's or CW's defense here, only trying to get a better grasp on things as I also use Sonar and so have a keen interest in this situation.

[Pete Kaine]

May I presume you've been dealing with this issue as posted over in the CW forum?

You may presume correctly.

If so, was a discrete USB controller card ever tried in lieu of the onboard USB ports?

One is fitted within the system and it shows no benefits above and beyond the native controller solution.

The reasons I ask are because, firstly, the OP in that CW forum thread never responded about that,

We managed to get hold of one of the CW developers around that time that the OP had dealt with previously and we choose to persue that angle.

and, secondly, as you are no doubt aware, Intel rather radically changed their chipset USB controller topology when moving from their X58 platform (having a separate I/O controller hub (ICH 10) from which all USB connectivity was provided) to their X79 platform (in which the PCH now integrates all former ICH functions including USB), replacing their ICH's discrete UHCI/EHCI duality and port switching logic with a new PCH "rate matching hub" tier and no discrete UHCI. This change also affected Intel's 6-series (Sandy Bridge) and newer PCHs as used on desktop and mobile.

In this regard, note that the X79 USB controller's "rate matching hub" appears to software as an external USB hub (tier). Note also that Roland do state in the VS-700 manual (Memo on p.27):

Yep, a point I spent a few months trying to make before someone got around to building a rig to test it on and realising that it was the case.

The VS-700 may not be recognized correctly if you’re using a USB hub. In this case, connect it directly to a USB port on your computer.

Hmm...

Hmmm... indeed.

Although it's odd that another poster in that CW forum thread had a very similar VS-700 and X79 setup using the same make mobo as the OP and reported things worked at low ASIO buffers.

And that tripped us up for a period that had me banging my head against any solid object that was in reach.

The inital rig that went out had a graphical glitching error within CW that came down to the X2A update and windows 7. We chased our tails trying to resolve that and as we did we discovered different bugs in different configuration setups that seemed to get more and more crazy as we went along. We managed to get the inital graphical issue replicated with CW support and it's being looked at, but otherwise it was fairly usable as a set up and may not have been a game breaker for some users. Over the course of this we've found, documented and submitted half a dozen bugs and issues and in most cases it was questioned regarding the configuration or platform, so at one point I had X58, Z77, &79 and AM3 rigs all set up side by side with matching window images (well as close as I could get) just so I could replicate problems across multiple platforms and prove it wasn't a "configuration problem".

Just to be clear (don't want you to think I'm calling you out!) I'm not coming to Roland's or CW's defense here, only trying to get a better grasp on things as I also use Sonar and so have a keen interest in this situation.

I may have been a little wound up and jumped in prematurely on Friday tbh. I've been dealing with this issue since around March now and it's one of those situations where my inital thoughts were close to the mark but the "configuration" card kept getting played. Mentally it's absolutely drained me and the clients suffered due to serious studio downtime, it's nice to get some varification that I'm not loosing the plot here.

*Edit* Just read Sam's article and it's an interesting read in that it backs up my thoughts on it. I'll just add that my client is working at 48,000/96,000 most of the time and the problems become far more obvious if your working at more the higher more intensive rates.

[TAFKAT]

Just a quick update.



I managed to get in front of a Mackie Onyx Blackbird this week , which like Focusrite and Presonus , etc, use the TC Applied Dice FW controller and base driver. I am happy to report that the unit has been updated to also be using the TC applied V4.x driver that has dramatically improved performance as it did for the previously mentioned.

The Mackie Unit has lower latency converters than the tested Presonus and Focusrite units , resulting in a lower RTL , placing the above those in LLP Ratings, just below the UFX Firewire.

Results were a little down perhaps because of the 4.1 version driver , but overall a very impressive result which has elevated the unit IMO to a very attractive option.

I know a few reading in were not happy about my previous reports on the Mackie interfaces tested, but I can only report as the units perform on the reference system , hopefully this will ease some of the qualms.

Peace

V.