Search form

[TAFKAT]

Hey All,

I am sure all of us have seen posts over the years where end users have purchased a new audio interface and have experienced varying degrees of performance issues. A lot of the qualms have been due to the low latency performance, or to be exact, lack of , so I thought it would be a good idea to place the spotlight on that specific aspect of the current crop of audio interfaces.

By testing the interfaces head to head and reporting warts and all, I hope to place some of these developers on notice that jamming as many shiny baubles onto an interface , but neglecting the crucial aspect of the actual driver performance , isn't going to swing for all of us.

I have been working on this for about 15 months odd so the preliminary results were actually from earlier in 2010 , but are still valid and are a good starting point as I add further to the list over the coming month/years.

Here are some initial results for both Desktop and Notebook .

Desktop System Detail:
Intel i7 920 Quadcore/ 2.66 GHZ/
Intel X58 / 6 GB DDR3-PC12800.

Notebook System Detail:
Intel i7 620 Dualcore / 2.66 GHZ/
Intel HM55 / 4 GB DDR3-PC10600.

O.S Detail:
Windows 7 x64 Pro





All of the interfaces listed except for the baseline RME HDSPe units are FW and its quite obvious from the results that there are large variables in LLP- Low Latency Performance depending on the efficiency of the respective ASIO drivers / FW controllers being employed on the respective interfaces.

I have posted a summary of the initial testing at the DAWbench site Here : http://www.dawbench.com/audio-int-lowlatency.htm

I have a second round of testing on the way which will include some of the newer AVID interfaces at both ends of the spectrum , Mbox Pro 3 and also one that I have had quite a few requests to put the thru its paces, the PTHD Native PCIe card.

Stay Tuned

Peace

Vin Curigliano
AAVIM Technology

[Pete Kaine]

Whilst I knew Maudio were doing a good job in keeping up with RME these days, I'm quite shocked to see Focusrite trailing by those figures. I'm not however suprised to see the Focusrite and the Presonus coming out the same through as they are both built around the same controller chipset... also nice to see that my contempt for its abilitys is well founded!

[redleicester]

Yet another good reason to stick with RME. Low latency and rock solid driver sets for a decade now. Great stuff.

[Martin Walker]

Hi Vin,

I bet you’ll end up taking a lot of flak for these measurements (although your armour-plated shell must be largely impervious by now), but I have to say that my own recent measurements of low latency performance by audio interface manufacturer do largely tie in with these :headbang:

RME have slipped a little on occasions with driver performance (as sadly have Lynx Audio, who used to be up there at the top with them), but it’s good to M Audio come back with such comparatively good results 8-)


Martin

[Parco]

So how about the echo audio? :headbang:

[TAFKAT]

Hey Guys,

I think its high time we collectively hold these audio developers accountable for the delivered driver performance , and its just becoming more and more of a bloody minefield lately as more and more developers simply tack on these generic OEM FW controllers without any regard of the overall performance. The recent spate of mixers/come audio interfaces are prime examples , and there is one currently extremely popular "Digital Live " mixer that has the worst drivers I have encountered in all my years, even worse than Dice II , and they market it as perfect for studio use, I almost fell flat on my arse laughing qualifying it a while back. I'll hold my cards on that one for now...:-)

Re The Dice II powered interfaces , as bad as they perform on DAWbench DSP, on DAWbench VI its even more pronounced where I recently tested a Focusrite unit which collapsed under that test to the point of it being practically unusable for anyone working with sample based VI's at the preferred working latencies. Those ongoing results can be read at the DAWbench forum thread until I finalise the second report.

Thread is Here

Out of interest , in the recent review in SOS of an "unlocked" Sandybridge system that was shipped with a - quote "well‑known Firewire audio interface" to Martin for review, that then had to subsequently be replaced to get a respectable test result, it would be interesting to get some clarification on what that interface was.

Now I know that is walking a very sensitive line for Martin seeing the name of the interface was withheld , but I am not asking Martin, I'm asking the DAW builder who supplied the unit to disclose what he supplied for the review, and I feel he should be extremely grateful that Martin went the extra yard instead of just reviewing as supplied :-)

@ Parco,

Interestingly with the ECHO, I just completed a config for a client with his existing Layla 24 under Win7 x64, and it performed reasonably well against the current crop of PCIe cards, but it does have the trick of using double buffers on playback which becomes a juggle with Round Trip Latency using Guitar Amp sims for example. You can wind it down to the 032/064 setting when tracking the guitars thru the sim, and it felt quite comfortable. Drivers are very solid overall.

Peace

V:

[Parco]

And so how about the Apogee and Motu?

[CaptainChoptastic]

Hmmm, somewhat disturbing news, given that I have a Focusrite Saffire Pro 24 DSP (kind of rolls off the tongue, don't it?). It doesn't mention the FW chipset on the spec sheet, but given the above and the reference to JetPLL, it's probably all but a given.

Vin: as you were running this under Win 7 x64, can you tell us if you were using the "regular" Win 7 FW drivers, or the legacy ones that Focusrite mention on their site as potentially having better performance under x64?

[TAFKAT]

Vin: as you were running this under Win 7 x64, can you tell us if you were using the "regular" Win 7 FW drivers, or the legacy ones that Focusrite mention on their site as potentially having better performance under x64?

Hey ,

The Focusrite and most of the Presonus units are definitely using the Dice II chipset , no question whats so ever.

Test system is actually running under the legacy FW at the moment due to the large number of interfaces that are constantly on and off the rig. In testing I found that even units like the RME's that run fine under Native FW drivers( TI in this case ), do have a small performance advantage under legacy as well at the lowest latencies 48 , but by 064 it levels out. In short there is no disadvantage running the legacy drivers, so I leave them on as default , but also test and compare with the native as new drivers come out.

To add insult to injury, I can't get the Dice II interfaces to be even recognised on my new audio notebooks at all ,due to the inability of getting a TI controller option , and this will become even more wide spread . I suspect Apple have also dropped TI on the new line and lack of Express slots becoming the norm, this is sounding loud bells for these interfaces.

Lets hope the devs don't play Ostrich.

I digress..

Peace

V:

[Dishpan]

Can I ask: are you including information on the safety (and other) buffers used, as well as the buffer size set in the application. There is quite a difference here between manufacturers and by way of a (possible exaggerated example), a system with 40 sample safety buffer and 32 sample latency (set in DAW) would have the same overall latency as a system with an 8 sample safety buffer and 64 sample latency set in DAW, yet on the charts you'd show them at different latencies making the first system look far more efficient than the second.

[TAFKAT]

Can I ask: are you including information on the safety (and other) buffers used, as well as the buffer size set in the application. There is quite a difference here between manufacturers and by way of a (possible exaggerated example), a system with 40 sample safety buffer and 32 sample latency (set in DAW) would have the same overall latency as a system with an 8 sample safety buffer and 64 sample latency set in DAW, yet on the charts you'd show them at different latencies making the first system look far more efficient than the second.

I hear ya.. :-)

Yes I am including all that info ,I make a note of that in the initial article and all of the actual I/O latency figures for the respective interfaces are listed with the results on the dedicated thread at DAWbench.

I'll create some charts to show the total I/O and Round Trip figures for each respective interface as I progress.

It needs to be noted that the output buffer value is the one that takes precedent on these tests , so the devs who use the double buffer trick will be definitely be highlighted, none of the listed used that tweak and although output value differed, there was not huge discrepancies.

Thats not to say the Input value and or RT - Round Trip - is any less important, because its those values that takes precedent when playing the Virtual Instruments live and Guitar Amp Sims for example.

Peace

V:

[robinv]

Hey Guys,

I think its high time we collectively hold these audio developers accountable for the delivered driver performance , and its just becoming more and more of a bloody minefield lately as more and more developers simply tack on these generic OEM FW controllers without any regard of the overall performance.

Hi Vin,
I'm not convinced that developers disregard overall performance quite like that. I imagine they work very hard trying to get their interfaces to do the job. It also depends on who you talk to as to where they believe the challenges lie.

You should bear in mind that there are many many happy users out there - the best feedback a manufacturer gets is in sales and returns. Obviously clever marketing and features can get the sales but if the performance was "unworkable" then they would become quickly aware of that you would think. You look at performance from a bit of a narrow perspective - from your position of scrutinising latencies of 64 samples and such (and you've been doing it for years) i can totally understand your concerns. My experience in the industry is a bit different and i find that most people i encounter are using buffer sizes of 256 or 512 samples very happily - this is where your tests show a bit more of an even level of performance. I know that there are people for whom this is completely unacceptable and unusable but i would suggest that there are many many more for whom it's completely fine and "real-time" etc etc.

I did my own tests on some interfaces last year when i was looking for a new laptop and i compared an Edirol FA66, Saffire Pro 24 and Presonus Firestudio and there were marked differences between the Firestudio and Saffire so i'm not convinced that they are the same, at least these models weren't. The Edirol beat the other two by a huge margin and it has very unsophisticated driver set with bugger all control panel ( http://www.pc-music.com/content/lifting-lid-audio-laptops-part-2 ). I was shocked at how poorly the Firestudio performed in these tests. However I have run them on desktop machines and other laptops without problems at the usual 256/512 level. The Saffire did all right i thought :)

I guess it comes down to what you believe is "fit for purpose". It might be more interesting to find out what sort of buffer sizes people actually use - i don't imagine many venture below 256 samples (but i could be totally wrong but i'm going on the complete lack of having to do tech support for latency related issues). You'll note that the only trouble Martin had in his review is when running your low latency tests - any other test that both he and i did before sending it out using what i'd suggest are more common buffer sizes, it performed fine.

I think comparing audio interfaces like this is a really great idea and will generate a lot of useful data that will help people chose the right interface for them - good on ya mate. Similarly the Cubase/Pro Tools comparison is a real eye-opener. But i also don't believe this level of low latency is the whole story for everyone. Not sure you're going to start a revolution but any improvement to driver performance is certainly a good thing :protest:

So, yeah, you know, different perspectives and stuff :)

[onesecondglance]

this stuff is fascinating as always, Vin. i would be very interested to see how higher end FW stuff like Prism and Apogee stack up in this dept.

[Spangler]

Fine for mixing, but for playing virtual instruments or realtime FX, I'm one of those who need it a lot tighter. Playing eDrums through Superior, anything over 64 samples is no good on my interface (of course midi performance also comes into play in that scenario).

My experience in the industry is a bit different and i find that most people i encounter are using buffer sizes of 256 or 512 samples very happily - this is where your tests show a bit more of an even level of performance. I know that there are people for whom this is completely unacceptable and unusable but i would suggest that there are many many more for whom it's completely fine and "real-time" etc etc.

[Martin Walker]

It looks as if I ought to set up a thread/poll so SOS Forum users can tell us what buffer size they currently use, and for what purpose (live monitoring, playing softsynths, or mixing/mastering), so we can all get a better handle on who wants what ;)


Martin

[TAFKAT]

You should bear in mind that there are many many happy users out there - the best feedback a manufacturer gets is in sales and returns. Obviously clever marketing and features can get the sales but if the performance was "unworkable" then they would become quickly aware of that you would think.

Horses for courses, we may have a different client demographic.

You look at performance from a bit of a narrow perspective - from your position of scrutinising latencies of 64 samples and such (and you've been doing it for years) i can totally understand your concerns. My experience in the industry is a bit different and i find that most people i encounter are using buffer sizes of 256 or 512 samples very happily - this is where your tests show a bit more of an even level of performance. I know that there are people for whom this is completely unacceptable and unusable but i would suggest that there are many many more for whom it's completely fine and "real-time" etc etc.

My work over the years in regards to focusing on native low latencies performance was due to direct requests and demands from my client base , and the volumes of traffic across multiple forums that I was active on. You may feel its narrow, but again we have a different demographic.

For those not requiring the lower latencies then the interfaces that are being highlighted as performing badly at those latencies are a non event , but I disagree that the majority of clients working latencies are 256/512, anyone who can actually play would not be comfortable using a VI at those latencies, I know I wouldn't. Also current systems with good audio interfaces can easily be set and forgot at those lower latencies and not have to do the buffer juggle if they decided to go back and do an overdub when mixing , for example. Also many composers process while they compose so again the lower latencies are extremely important.

I did my own tests on some interfaces last year when i was looking for a new laptop and i compared an Edirol FA66, Saffire Pro 24 and Presonus Firestudio and there were marked differences between the Firestudio and Saffire so i'm not convinced that they are the same, at least these models weren't.

Its a constantly moving target, Presonus use multiple OEM FW controllers across the range, its why they have different drivers and not one universal one. Also I did have some variance between the 2 on my notebook testing , so there is some wiggle room in how they tweak the drivers perhaps.

You'll note that the only trouble Martin had in his review is when running your low latency tests - any other test that both he and i did before sending it out using what i'd suggest are more common buffer sizes, it performed fine.

Be very grateful he wasn't using DAWbench VI as a reference test, as the "unnamed" interface would have fallen in a heap at the working latencies anyone would use for live playing of VI's , right up to 256 samples. 512 was O.K in the test without convolution verbs, it stalled with, but seriously Mate , 512 samples is purely for mixing only. You can't play a VI comfortably at that level, you can't use a Guitar Amp Sim, you can't play live MIDI drums into a Drum Sampler , etc, etc.

In short it simply negates a huge potential of the advantages we enjoy using these current uber fast systems.

I think comparing audio interfaces like this is a really great idea and will generate a lot of useful data that will help people chose the right interface for them - good on ya mate.

That's the aim.

Not sure you're going to start a revolution but any improvement to driver performance is certainly a good thing

I'll call and raise ya... :-)

The past work has already resulted in better drivers and multiprocessor performance on some DAW hosts , revolution may be too lofty, but this will grow legs , how hairy will be up to the audio hardware developers.

Lets see where the dust settles.

Yes I have my helmet and armour on.. :-)

P.S: you still haven't disclosed the interface used in the review, if its such a non event, then it shouldn't be a problem.. :-)

Peace

V:

[mhaigh]

It might be more interesting to find out what sort of buffer sizes people actually use - i don't imagine many venture below 256 samples (but i could be totally wrong but i'm going on the complete lack of having to do tech support for latency related issues).

hi Robin
i run an echo audiofire 2 and find their drivers totally stable. As Vin says, Echo use double safety buffers, but I ALWAYS run at 128 samples, whether tracking or mixing. I can go to 64 samples but i find this makes the system a little unstable, but no issues at 128. This is on a totally unoptimised i5 750/win7 x64/4gb system with onboard FW (ASRock mobo!) bought from eBay for about £400, with wireless ON and also Avast AV...seriously good drivers, mate. A typical project runs 8- 10 instances of Guitar Rig 4, Steven Slate (Kontakt 4) drums and a couple of VSTIs...and obviously various FX when when mixing, including convo reverbs and look ahead FX like T-Racks Algo EQ...

[robinv]

Horses for courses, we may have a different client demographic.

Maybe - and thanks for taking my comments in the spirit they were meant. I didn't mean "narrow" as a criticism either, rather just indicating where your focus lies - which is fine! I wasn't making any criticisms just talking from another viewpoint :)

but I disagree that the majority of clients working latencies are 256/512, anyone who can actually play would not be comfortable using a VI at those latencies, I know I wouldn't.

But that's a judgement call - i play, can "actually" play guitar, keyboards and percussion. I use an Alesis Performance pad to enter drum tracks using Battery or Abbey Road on 256 samples - i havent moved the buffer in years. I do everything in the box, effects, instruments the lot. Either i'm an idiot or perhaps it's not as unplayable as you suggest, or at least to everyone - i concede that i might be an idiot.

In short it simply negates a huge potential of the advantages we enjoy using these current uber fast systems.

That suggests that one can only enjoy their system if they are running it at "acceptable" latencies as defined by you. I don't think any one chooses to make their system unplayable - i dont opt for 256 because i like a bit of lag, it's rather that it doesnt occur to me to change it because for me there is no lag, it is real-time and i dont need to sacrifice more CPU cycles to get it better than real-time.

My point about the tech support is that honestly i havent had a call in years about latency and i regularly supply Focusrite, Presonus, Steinberg and RME interfaces set to 256 as default. I don't doubt that other people have different needs but i remain unconvinced that it's all about the buffer size, and what people believe is playable can vary.

The past work has already resulted in better drivers and multiprocessor performance on some DAW hosts , revolution may be too lofty, but this will grow legs , how hairy will be up to the audio hardware developers.

That's excellent mate. If you talk to Digi then you'll find it's all Microsoft's fault and their appalling implementation of the firewire protocol, so you'd best get Balmer in your sights too :)

Which reminds me - do you have any reference data of buffer sizes on the Mac?

[Pete Kaine]

I agree with you to a point Robin but I'm very much in Vin's camp in wanting to see certain firms get a kick up the arse.

I've been heard to mutter about the DICE controller any number of times now and an engineer I've worked with was sent the DICE development pack for use in his use in developing interfaces when it was first brought to market, and after some time with it he simply decided it wasn't good enoough for the project they were doing and for me that is the right attitude.

My own testing be it Alesis, Focusrite, Prosonus shows up performance loss (I know the's a few more names out there with problems that I haven't tested) compared to other cards not using this generic solution that perform far better. I have to ask myself why would I wish to recommend one of those interfaces when i know other brands can outperfom them?

Focusrite I stick with for it's well regarded signal chain, and I'll recommend those to players who want a good cheap "recording" device working with a limited number of channels of audio, but I wouldn't be so keen to offer them to someone working with electronica or mixing and processing heavily in the box who needs the performance.

Given those reasons why would I want to recommend a device from the other two above when I know I already stock better hardware than those in regards to performance when we should be guiding end users to the most suitable packages for their requirements?

Why put in the effort to develop well tuned systems as DAW builders if we're going to hamstring ourselves with substandard interfaces?

I'd say the vast majority of the time I get a customer with an interface problem it's a DICE box... Why would i want to go with a solution that I know can be problematic when the end user just want's a box that works?

As much as I'd love to see it I don't see the firms out there making the effort to invest in new solutions, otherwise they would have done already instead of going off the shelf with their current models. But any tuning of the drivers that a thorn in the side campaign brings can only be a good thing.

*Edit* Robin - A lot of those devices work great on mac's and don't seem to have the same issue they do on the P.C. The's a couple I tested as being unusable on the P.C. which run fine on a MAC so yeah the cat calling over Windows firewire implimentation has some merit...

But we're talking about half a dozen firms using the SAME controller solution which they apparently know doesn't work great in windows.

In that case stop wingeing about the windows implimentaion and do something about your code! The's a load of you surely you can pool your resources and do something about it rather than just shrug your shoulders and point the blame! If Maudio can get it right in their budget end of the market then what excuse do the rest of them have?

[TAFKAT]

That suggests that one can only enjoy their system if they are running it at "acceptable" latencies as defined by you. I don't think any one chooses to make their system unplayable - i dont opt for 256 because i like a bit of lag, it's rather that it doesnt occur to me to change it because for me there is no lag, it is real-time and i dont need to sacrifice more CPU cycles to get it better than real-time.

Hang on, I am not making any suggestions of the sort , also what is an acceptable latency is defined by the individual end user and their working environments and requirements. 256 samples is not real time when using RTL- Round Trip Latency,anything above 064 will actually feel laggy for guitarists , I personally know drummers who are even further hampered , so just because your working environment works for you, it doesn't mean it will for others. That doesn't make you any more or less an idiot or otherwise, than those that will not find 256 acceptable.

Re CPU cycles, a good audio interface with efficient drivers will have minimal variance between the moderate latencies of 064/128 , I have seen variables as low as 20% between 032 samples and 256 when scaled to break, so if you are getting substantial CPU cycle hits running anything below 256, then I would be taking a serious look at the interface you are using.

I don't doubt that other people have different needs but i remain unconvinced that it's all about the buffer size, and what people believe is playable can vary.

While you place far less importance on efficient LLP , I have yet to see an audio interface manufacturer market their products in that manner, quite the opposite. Most if not all will try and sell the merits of low latency , whether they can actually deliver the efficiency is another matter. If it was of no importance to the end users, why would they bother emphasizing the low latency aspect.

If you talk to Digi then you'll find it's all Microsoft's fault and their appalling implementation of the firewire protocol, so you'd best get Balmer in your sights too :)

Interestingly the new AVID MboxPro 3 is outperforming both the M-Audio and the RME's on some recent testing I have done, even on a non TI generic OHCI FW controller on my latest audio notebook , while a Focusrite unit would not even be detected at all, so I think Digi and Microsoft are in the clear, Focusrite/DiceII on the other hand.....

Which reminds me - do you have any reference data of buffer sizes on the Mac?

Well thats a whole other thread as Core Audio is inherently not as efficient as ASIO , plus the cross platform Hosts are not on par , so its kind of harder to get a head to head. I did some testing with RME/M-Audio in the last batch of cross platform DAW testing , and in short, the windows hosts / ASIO driver at any of the respective latencies are more efficient.

I do plan to include more OSX comparative data if there is enough interest from that side of the pond.

Peace

V: