PM sent.

What did the utility say about the i/f's that DO report nominal?

Hey John,

I noted in an earlier post but you may have missed it.

Both the ESI's are using double playback buffering.. :-(

Their ratings have dropped accordingly... :-)

V:

Hi Vin,

You're right . . . I missed that.

Are we talking about a double RAM buffer, or additional buffering in the interface hardware?

On a connected note, I did notice in Craig Anderton's screenshot that there is a menu item labelled 'buffers in playback queue', which is set to two.

Cheers,

John

Hey John,

I suspect the added buffering on the ESI units is the driver itself , its hard to tell with just the calculated RTL value whether its added to both I / O or just the Output , but the RTL is quite high.

It took some work to get the results as well, whereas on the RME units it was relatively easy. Having another look at the results they are exceptionally high , I doubt the AD/DA's / FPGA/DSP could account for such a measurable increase. I do have to revisit them again before posting the results , but needless to say they are close to the bottom of the table listing now.

Re the "Buffers In Playback Queue" setting in Sonar, from my understanding that is the amount of buffers that Sonar reads ahead before playback, it has no correlation to the actual buffer size/ latency, but can be used to smooth out playback.

V:

Just to add a few more curves into the mix..,

Doing some double checking of the data I suspect the MOTU 424/24 I/O and RTL values may only be for the driver/safety buffers and DSP, excluding the AD/DA. I am having that checked for me by a client with the MOTU unit as I no longer have it in my possession.

The fun continues.. :-)

V:

Quick update,

As suspected the MOTU was only reporting the driver/safety buffers sans AD/DA , which added another 98 samples to the RTL across the board at each buffer setting.

I have completed the UFX testing with some interesting and rather pleasing results on the FW side considering that the unit no longer has a dedicated FW controller , simply uses the FPGA for all on the control/arbitration now. Slightly better performance than the FW800 with lower I/O and RTL due to the tighter AD/DA.

I am just holding off posting the results for the time being as I need to confirm one last variable which is the new MultiClient Mixing option on the USB side, that I need to cross reference against a driver that does not have that feature. Of course I skipped a couple of driver versions so just waiting on a copy of the last revision of the driver sans the MCM. I had the appropriate version for the FW side and it is the same version I had tested the FW800 with, so all good there. I am told by M.C from RME that the next version of the FW/USB drivers will have the available option check box the same as the HDSPe drivers.

Also in light of the recent discovery on interface drivers sometimes not reporting AD/DA , I need to go back and double check the AVID/M Audio FW and USB units that are reporting identical values for I/O , which is a little suspicious.

What have I got myself into ... LOL

Stay Tuned

V:

>Also in light of the recent discovery on interface drivers sometimes not reporting AD/DA , I need to go back and double check the AVID/M Audio FW and USB units that are reporting identical values for I/O , which is a little suspicious.

A recent discovery? This has ALWAYS been the case for some models! I did similar research on this years ago and hardly any of the interfaces then reported convertor latency. I resorted to brute-force testing to get precise figures. Remember it's not just AD/DA either, certain cards (such as MADI etc.) can add extra samples for conversions to these protocols (although to be fair this isn't usually significant) and again, this is often NOT reported so ensure you include this too!. So you have that plus buffer plus safety to contend with! It really is a minefield

Quote Dishpan:

---

A recent discovery? This has ALWAYS been the case for some models! I did similar research on this years ago and hardly any of the interfaces then reported convertor latency.

---

Care to share that data ?

BTW - I didn't mean it as some global revelation, it was meant from a personal perspective only.

Also I was quite familiar that when using external AD/DA's via ADAT/AES/MADI in some cases the AD/DA were ignored , especially when mixing and matching cards/converters from different manufacturers. I was a little surprised that the RME HDSP AES/ADIQS combo also didn't report the AD/DA tho.

FWIW: the Lynx AES/ Auroro combo I am told do report the AD/DA latencies via the ASIO driver to the Host via the standard AES connection.

I was more surprised by the fact that the MOTU units that use a proprietary protocol would also ignore the AD/DA and will be even more disappointed if the AVID/M-Audio are also ignoring the onboard AD/DA.

My comment needs to be taken in that context.

Quote:

---

Remember it's not just AD/DA either, certain cards (such as MADI etc.) can add extra samples for conversions to these protocols (although to be fair this isn't usually significant) and again, this is often NOT reported so ensure you include this too!. So you have that plus buffer plus safety to contend with! It really is a minefield

---

The RME units with the onboard AD/DA that I double checked with the RTL Utility report all of the latencies from my calcs via the ASIO driver to the hosts, that includes the safety buffers/FGPA as well , the AES card reported all minus the AD/DA.

The further I get into this the more I realise I have opened a can of worms of huge proportions, a minefield it is , but one I am right in the middle of carefully navigating as best I can. It is also harder when I am doing this on my own and against the grain of some of the manufacturers as well , who would be less then ecstatic about the laundry being aired , but there is no turning back now... :-)

V:

I think it is great that you are independently doing these measurements. From the perspective of live recording of percussion and other rhythmic instruments, measuring and minimizing latency is an important issue.
Your methodology does seem to be getting more complicated, and my naive question is, why not measure a simple total round trip latency directly? For example, record a rim shot or some other short sound with steep initial slope of the waveform, play it back through a headphone with your measurement mic inside the phones while recording the played back sound, then read the total round trip latency directly off of the time axis of the recorded waveform.
It may not answer all questions for those who use synthesizers, midi, etc, but I don't see any potential sources of significant errors with that method (which replicates a live recording situation), and it would seem to be reproducible and usable unmodified with any interface and hardware/software setup. Perhaps you are doing this already and I just don't know how to interpret your reported data. Am I missing something?

Edited by Jorge (08/08/11 12:55 AM)

Quote Jorge:

---

I think it is great that you are independently doing these measurements. From the perspective of live recording of percussion and other rhythmic instruments, measuring and minimizing latency is an important issue.
Your methodology does seem to be getting more complicated, and my naive question is, why not measure a simple total round trip latency directly? For example, record a rim shot or some other short sound with steep initial slope of the waveform, play it back through a headphone with your measurement mic inside the phones while recording the played back sound, then read the total round trip latency directly off of the time axis of the recorded waveform.

---

Hi Jorge!

Vin is effectively doing this, but creating a dedicated utility makes things even quicker and less prone to user error.

For instance, I’ve measured a load of interfaces using the ‘record the click and look at the time difference’, and once you’ve introduced a sequencer for the recording you also have to double check that any auto-quantise is disabled, as well as any other latency compensation tweakery.

With a dedicated utility everyone can measure EXACTLY the same thing for themselves without worrying about any of this stuff


Martin

--------------------
YewTreeMagic

Thanks, Martin. It does seem that there are potential confounding factors I had not considered, and a utility that accounts for these and gives reproducible results would be useful. The comparative results for a range of popular interfaces tested under identical conditions using such a utility would be very useful for end users like me. I can certainly see the potential for resistance from manufacturers. Vin, I give you great credit for dealing with that and to SOS for supporting a project like this on your forums.

Hey Jorge,

Martin beat me to the punch.. :-)

The Utility will be available to all once we settle on a final build and it will definitely be of benefit to many I believe.

IMO - the only manufacturers that will have resistance to this project are those that have something to hide. This could be of enormous benefit across the board for all involved if taken in a positive manner , but some are not really open to taking the data in that light, only seeing it as criticism. How they actually respond to the available data ( if they do at all ) is the real litmus test to their respective approach , lets see where the dust settles.




V:

Quote TAFKAT:

---

IMO - the only manufacturers that will have resistance to this project are those that have something to hide. This could be of enormous benefit across the board for all involved if taken in a positive manner , but some are not really open to taking the data in that light, only seeing it as criticism. How they actually respond to the available data ( if they do at all ) is the real litmus test to their respective approach , lets see where the dust settles.




V:

---

For the sake of being a cheeky devils advocate - you are assuming that manufacturers have even heard of you and your little test or give a toss about your opinion or findings. You do talk as if they are hanging on your every word, desperate for your approval and that not to do so means they are evil people hoping to screw people out of latency while wringing their hands and cackling. You've already posted results and graphs and then had to change them which doesn't really do the seriousness of your claims any good (i have personal experience of this sort of thing). Also you are pinning everything on a single attribute. I don't think anyone would like their product compared and rated on a single factor. I wouldn't like to see a Rain computer put along side computers from every competitor and measured/judged purely on maximum number of plug-ins run because it doesn't take into account the whole environment in which that measurement exists - there are always a number of factors involved in choosing a product.

However, all us freaks on this forum are eagerly fascinated by what you're doing and all hoping it helps to improve the performance of interfaces in the future

--------------------
PC-Music.com hints, tips & reviews
Rain Computers UK - Creative Audio PC's

Quote robinv:

---

For the sake of being a cheeky devils advocate - you are assuming that manufacturers have even heard of you and your little test or give a toss about your opinion or findings. You do talk as if they are hanging on your every word, desperate for your approval and that not to do so means they are evil people hoping to screw people out of latency while wringing their hands and cackling.

---

I don't assume anything Mate, and as for whether they are aware of me or give a toss , thats two totally different things. I am pretty sure some are aware of my work over the years , whether they give a toss is another matter.

Hmm, maybe I should have a signature with a direct link to my websites to help them find me if need be... :-)

I can safely say I know of more than a few who respect the work and are very conscious of the comparative LLP performance of their units.

As to my little test , you are dismissing the volume of work I have assigned to this endeavour as little ?

As to the manufacturers hanging on my every word , I doubt it, nor do I care. I am simply reporting as the chips fall , whether they read in , ignore , dismiss or other wise isn't the primary concern. Those that take issue know where to find me, those that want to work with me know like wise, and those that choose to ignore me, well, more power to them :-)

Interestingly I do get some nice toys sent over to play with , qualify and report back warts and all. I have a healthy qualifying list of hardware on site at all times , it does keep things interesting and in perspective.

Quote:

---

You've already posted results and graphs and then had to change them which doesn't really do the seriousness of your claims any good (i have personal experience of this sort of thing).

---

So you are questioning the credibility of the data because I am being totally transparent and amending it as I progress further , wow that's interesting I have to say. Also the amendments haven't changed anything in regards to the bulk of the work, only those interfaces that either reported nominal or needed further clarification with the AD/DA values.

This is work in progress and I am amending the results as further variables come into play, how can you possibly be finding fault with that. I am publicly disclosing and amending any results that have a question mark over them. As to your personal experience , please don't compare my current contributions to your instance.

You posted blatantly skewed data that you never followed up on or retracted despite myself and numerous others pointing it out to you very early on , reasonably politely I might add. Then 12 months on you posted an amended report with results that were the total opposite of the previous report. The results coincided with data that I and others had previously presented you, there was absolutely no mention , apology or retraction of the previous report which was conveniently deleted.

I think our experiences differ there Mate, I am happy to eat crow if I have screwed up on any data presented , I didn't see the same courtesy from you. BTW: Its quite tasty baked with a touch of salt & lemon.. :-)

Quote:

---

Also you are pinning everything on a single attribute. I don't think anyone would like their product compared and rated on a single factor.

---

I made it abundantly clear right from the get go that I was focusing purely on the LLP aspect , the rating is pretty straight forward , its a Low Latency Performance Rating, nothing more, there are plenty of other reviewers doing the comparative reviews focussing on other attributes.

But as you suggested earlier, why would the manufacturers even care about my LLP rating ?

Quote:

---

I wouldn't like to see a Rain computer put along side computers from every competitor and measured/judged purely on maximum number of plug-ins run because it doesn't take into account the whole environment in which that measurement exists - there are always a number of factors involved in choosing a product.

---

Right, I bet you hated all the positive commentary from that last SOS review system of yours based on the benchmarks you are now suggesting are pointless. ;-)

Of course there are plenty of factors involved in choosing an appropriate solution , one variable that is extremely important is matching the end users respective working environment with an audio interface solution that will best suit that environment. Perfect example, a client working with large sample based VI's at low to moderate latencies will not be well served with an interface that does not perform as well as others at those required latencies. All of the bells whistles and branding mean squat if it fails in that one single variable !

Quote:

---

However, all us freaks on this forum are eagerly fascinated by what you're doing and all hoping it helps to improve the performance of interfaces in the future

---

I'm confused, you seem to be trying to have a little bit each way :-(

On one hand you dismiss the work as being irrelevant to the manufacturers , but on the other hand you are hoping it may result in better drivers in future ??

Oh I get it, what your are saying is that you don't mind someone getting their hands bloodied for the benefit of all, as long as their not yours... :-)

V:

No you nut, i'm being "cheeky" for the sake of it - i'm poking a bit of fun, not making defining statements about you or your "little" test (that's meant as cheekiness, not sarcasm). I've said on here before that your work is brilliant, it's just sometimes it comes across a bit over-important and so that makes me want to tease you a little - it's just teasing mate. Your transparency is great but people do often take things at face value and don't read what was said and what i mean is that someone may take your results and buy a certain interface because you reported it as good only to find that you change the results later based upon new data. You're not measuring an actual latency at the moment you're calculating one. But none of that would be your fault, you're simply presenting your data. I'm not calling your results into question or disrespecting them in any way - all i'm saying is that caution is required.

Quote TAFKAT:

---

I don't assume anything Mate, and as for whether they are aware of me or give a toss , thats two totally different things. I am pretty sure some are aware of my work over the years , whether they give a toss is another matter.

---

Well, no, you said that if they didn't respond they must have something to hide so therefore you do assume they give a toss. And so i was teasing you about that assumption.

Quote:

---

This is work in progress and I am amending the results as further variables come into play, how can you possibly be finding fault with that. I am publicly disclosing and amending any results that have a question mark over them.

---

I'm not finding fault mate, i'm saying that people don't always read what you say and take many things to be gospel that perhaps weren't not intended as such - be cautious.

Quote:

---

I made it abundantly clear right from the get go that I was focusing purely on the LLP aspect , the rating is pretty straight forward , its a Low Latency Performance Rating, nothing more, there are plenty of other reviewers doing the comparative reviews focussing on other attributes.

---

Absolutely, but that's my point. You said that manufacturers would have something to hide if they didn't act on this single attribute whereas i'm just saying that i think it's a bigger picture than just that - for some people this is the only thing they care about and that's fine. It's the assumption you made about the manufacturers that i was poking fun at

Quote:

---

Right, I bet you hated all the positive commentary from that last SOS review system of yours based on the benchmarks you are now suggesting are pointless. ;-)

---

Oh it was so awful i almost left the country.

Quote:

---

Quote:

---

However, all us freaks on this forum are eagerly fascinated by what you're doing and all hoping it helps to improve the performance of interfaces in the future

---

I'm confused, you seem to be trying to have a little bit each way :-(

---

Both ways absolutely - i love your work man, i'm just poking a bit of fun at you, and y ou know that i have different opinions on these things and so i present a slightly different view - not to knock yours, just to offer some more flavours.

I don't dismiss your work in the slightest - i didn't ever say that and i am always happy to contribute to the discussion and to the work.

Obviously my post and teasing was misjudged and so i'm sorry about that Vin, didn't mean to rub you up the wrong way - unless it was funny, which it seems it wasn't.

You keep doing what you're doing and feel free to ignore me

--------------------
PC-Music.com hints, tips & reviews
Rain Computers UK - Creative Audio PC's

Quote robinv:

---

No you nut, i'm being "cheeky" for the sake of it - i'm poking a bit of fun, not making defining statements about you or your "little" test (that's meant as cheekiness, not sarcasm).

---

Sorry Mate, I totally misinterpreted, sometimes the intent is lost due to the non verbals that are the nature of the cyber beast... :-(

Quote:

---

Your transparency is great but people do often take things at face value and don't read what was said and what i mean is that someone may take your results and buy a certain interface because you reported it as good only to find that you change the results later based upon new data.

---

I hear ya, and its why I immediately came back and retracted my earlier praise of the ESI units when I discovered they were hiding huge safety and playback buffers by only reporting nominal. It has made me extremely cautious as I go forward with any and all interfaces now.

Quote:

---

You're not measuring an actual latency at the moment you're calculating one. But none of that would be your fault, you're simply presenting your data. I'm not calling your results into question or disrespecting them in any way - all i'm saying is that caution is required.

---

The ASIO driver protocol has the ability to report very accurately to the Host , something that Craig Anderton discovered when he went thru the manual exercise to find that he was within a few samples. The Utility being developed is using the same principle but in a more convenient manner which will hopefully minimise discrepancies that can be introduced trying to zoom in , select and measure manually.

Quote:

---

Well, no, you said that if they didn't respond they must have something to hide so therefore you do assume they give a toss. And so i was teasing you about that assumption

---

Ahhh yes assumptions are definitely a dangerous thing, but you are assuming that I was assuming, when actually I wasn't assuming anything at all .. LOL

What I said was that IMO the only manufacturers who would feel resistance to what I am doing would be those with something to hide , that could be anything from less then stellar driver efficiency to hiding extended safety and playback buffers. Thats not really an assumption its simply an opinion based on some behind the scenes communique. I am hoping to lift the veil as much as possible so that we are all more informed.

I know this is extremely sensitive for some parties dealing with the 3rd party OEM controllers being highlighted here , but the simple fact that all are dealing with the same deck , but some are performing substantially better than others. That alone should be enough for those not performing as well to look into why the variable exists at their end and improve on it, well at least I hope it would.

Quote:

---

Obviously my post and teasing was misjudged and so i'm sorry about that Vin, didn't mean to rub you up the wrong way - unless it was funny, which it seems it wasn't.

---

Its cool Mate, I usually pick up the intent on your posts pretty well, unfortunately I was reading the last one a little too diagonally , lets put it down to the coming full moon... :-)

All Good and thanks for responding in the manner you have.

I'll try and complete the testing on the current batch and get the amended charts/graphs up ASAP

Peace.

V:

Quote TAFKAT:

---

Ahhh yes assumptions are definitely a dangerous thing, but you are assuming that I was assuming, when actually I wasn't assuming anything at all .. LOL

---

Quote:

---

I'll try and complete the testing on the current batch and get the amended charts/graphs up ASAP

Peace.

V:

---

We're all looking forward to that
And remember i like graphs so that i don't have to actually read anything.

Cool mate.

--------------------
PC-Music.com hints, tips & reviews
Rain Computers UK - Creative Audio PC's

So we won't need a group hug after all


Martin

--------------------
YewTreeMagic

Ahhh what the he.., why not

Hey everybody,
I'm one of the people you write your reviews for (and a hopefully helpfull member of Dawbench, hey Vin, interesting discussion here). From my perspective, I have to agree 100% with Vin (Tafkat). LLP is an absolute, not a perception at all. It may not be easy to measure and quantise, but it is a value anyway. Just like for example mic preamp noise, what would "it is rather silent" mean exactly, I need figures and maybe a warning like yes the figures are low but it's an awfull digital kind of noise....
Without Vins help choosing an audio interface for me as an in the box composer is a complete nightmare. You spend lots of money on a fast machine and might achieve nothing but flawless iTunes playback .
Please reviewers don't underestimate the importance of LLP. I would guess it is the biggest difference between products apart from features (like how many in and outputs etc). Much more so then sound quality, which is much more related to price/budget IMHO.
BTW I own a HDSP9652 with ADI-8AE. Super performance....Great sound (yes these are absolutes )

--------------------
P5Q Q9550 @3.6ghz 8GB XP64 2XUAD-1
RME HDSP9652 ADI-8AE and Blue Sky System one

Hi vinark, and welcome to the SOS Forums!

Thanks for your comments. I totally agree about the LLP test, and have been measuring real-world latency myself during many SOS audio interface reviews over the years (and been shocked by all the ‘hidden extras’ found on some models )

Many musicians don’t seem too bothered about low latency performance except to complain that their computer can’t do it successfully, without realising that it may be their choice of audio interface to blame rather than the computer


Martin

--------------------
YewTreeMagic

I would just like to thank Vin for his work so far it has been very helpful for me in looking for an interface/soundcard for my itb work, and I'm sure it will be helpful to many like me who are beginners and are looking to compose with mainly virtual instruments and samples.

However, I settled on a soundcard outside your list - the perfect M-audio delta 66 (perfect for me), enough outs for multiple references, enough ins for a few synths and s/pdif! The latency on this thing is very good (anecdotal evidence suggests RTL below 5ms across various forums), it is stable, and the only thing not nice for me is the budget-level dac.

Your research saved me some time in looking for a low-latency gear, thankyou!

Hi Hardwinte, and welcome to the SOS Forums!

The Delta 66 has provided sterling service to a host of musicians over the years - I remember reviewing it for SOS way back in 2000. The audio quality of its AK4524 Codec chips has since been surpassed by quite a few other models, but it remains a budget workhorse for a lot of people.


Martin

--------------------
YewTreeMagic

Thanks Martin Walker

Funny side thing, but my previous english teacher's name was Mr Walker. (The **** actually kept on walking out of class and only turning up for half of our lessons... )

Not that he reflects on you at all, by the mere chance that you share a surname! No good sir, no, but if you could kindly talk some more about those better codecs I would appreciate it, made me all curious as I haven't actually bought my interface yet (no time, going through exams)

Well I don't want to hijack this thread - let me just say that the Delta 66 is a great interface, but was brought out ten years ago now, so newer models are likely to have more recent technology that might possibly have slightly better audio quality.


Martin

--------------------
YewTreeMagic

Hey All,

Thanks for the support and ongoing interest.. :-)

Just a few notes , re the Delta 66 ( or any PCI interface ), with the current Intel chipsets moving away from a legacy PCI buss unfortunately they will be less of a focus moving forward. My X58 test/development system luckily still has native PCI so I can achieve full performance on the older cards that are compatible, but current systems - P67/H67/Z68 on may not achieve full performance with PCI cards due to the 3rd party bridged PCI implementation.

It would be great if M-Audio updated the Delta range to PCIe as they have always been decent performers , I would also add Lynx to that list with their Lynx 2 range , but unfortunately it seems that most manufacturers are focusing on external connectivity as that gives a wider spread across both desktop and notebook markets. However its not all smooth sailing as witnessed with the variance with the FW controllers and now with the growing trend of manufacturers moving more and more to USB2 ( supposedly for greater compatibility ), its becoming even more of a crap shoot. Perfect case in point is the issue I encountered with the ESI U46XL that simply refused to enumerate and function correctly on H67/P67 , and the SSL Nuclues unit that was extremely inconsistent depending on the system and even USB port. I am also keeping a close eye on numerous reports of issues with other USB2 interfaces also being inconsistent.

Focusrite which has had a negative focus on my recent testing with the performance of the FW interfaces has recently introduced USB2 interfaces ( as has Presonus) , and already there are reports of inconsistencies and instability posted on this forum Here

Also take note of the reported latencies :-(

If any of the other DAW builders or end users with one of these new Focusrite units want to chip in with some testing/reports that would be great, not sure if/when I will have access to one.

I am currently buried with work unfortunately but I will drop back with some fresh results ASAP, I even dusted off an old Lynx2 PCI card to do some testing after a test loaner PCIe config fell thru , that should give a good indication at least of the current driver - AD/DA will not be as tight tho.

Stay Tuned

V:

Quote Martin Walker:

---

Well I don't want to hijack this thread - let me just say that the Delta 66 is a great interface, but was brought out ten years ago now, so newer models are likely to have more recent technology that might possibly have slightly better audio quality.


Martin

---

I'm still recording through my Delta 44/Omni io combination that i bought when they were released. In terms of features i haven't been able to find anything to replace it with. Still sounds ok to me

--------------------
PC-Music.com hints, tips & reviews
Rain Computers UK - Creative Audio PC's

Quote Martin Walker:

---

Well I don't want to hijack this thread - let me just say that the Delta 66 is a great interface, but was brought out ten years ago now, so newer models are likely to have more recent technology that might possibly have slightly better audio quality.


Martin

---

Care to name those 'newer models' Martin, just for reference?

I used a Delta 66 for a long while but had fairly frequent 'fizziness/crackles' when I recorded sometimes. It's not an uncommon issue with the Delta range. I wasted a lot of time on the MAudio forums, and others, searching for the Holy Grail solution, including trying arcane tweaks like changing power setups in the BIOS screen, etc. All to no avail.

I bought a new Sandy Bridge DAW in April and bought a Focusrite Saffire PRO14 for a change. I haven't experienced any of the 'Delta fizzies' and am fairly pleased with it. Then I read your recent SOS piece saying that Firewire isn't all it's cracked up to be and an internal card (a la Delta) is probably better! Do I assume from your comment above that as the Pro14 is much newer than the Delta 66 I nevertheless have some advantage?

John

--------------------
When I'm sad I sing, and then the whole world is sad with me.
Band / Songs

Quote Skyline:

---

Quote Martin Walker:

---

Well I don't want to hijack this thread - let me just say that the Delta 66 is a great interface, but was brought out ten years ago now, so newer models are likely to have more recent technology that might possibly have slightly better audio quality.


Martin

---

Care to name those 'newer models' Martin, just for reference?

---

Well let me just say that in terms of audio quality alone I would personally rate the Saffire and Konnekt ranges highly, although as we've been discussing here latency may be another matter to consider.


Martin

--------------------
YewTreeMagic

Hi Vin, have been testing a few units including the fore-mentioned Focusrite.
What do we do when the buffer size is in ms instead of samples?

Also, i'v e done head to head sound quality tests on a few units and can report minimal difference at 48k, at 96k it starts to get a bit different, but it pales into insignificance compared to choice of monitor speakers. The differences between the Mackie hr824, Neumann kh120 and Genelec 8030 are probably 50 times greater than between any of the interfaces ive tried so far.


Edited by Tombot (18/08/11 08:49 AM)

"It would be great if M-Audio updated the Delta range to PCIe as they have always been decent performers"
It would indeed TAFKAT but it isn't going to happen. I have had stirling service from my 2496's. They have worked flawlessly in XP and W7/64 and even with WMCE which is supposed to be a no-no!

So when I got my W7 PC my aim was to buy a pair of AP 192s to get 4 in 4 out with what were reckoned to be excellent new converters (Martin W said so!) I was crushed then to find my new PC had but one PCI slot. Ah well,I wil just wait for the PCIe versions and dropped an E to M-A asking about when. Never was the reply. They are not and will not be upgrading any soundcards to PCIe format, out of MOBO sound altogether.

Bloody outrageaous and commercially stupid IMHO.

Dave.

Quote Tombot:

---

Hi Vin, have been testing a few units including the fore-mentioned Focusrite.
What do we do when the buffer size is in ms instead of samples?

---

Hi Tombot!

You can convert farily easily.

For instance, at a sample rate of 44.1kHz, 1ms = 44 samples, at 96kHz, 1mS = 96 samples

As for your comments about audio quality, loudspeakers certainly vary a hell of a lot more than interfaces, but they can still be heard, particularly once you've got some acoustic treatment in place and some decent loudspeakers in place.


Martin

--------------------
YewTreeMagic

Quote ef37a:

---

"It would be great if M-Audio updated the Delta range to PCIe as they have always been decent performers"
It would indeed TAFKAT but it isn't going to happen. I have had stirling service from my 2496's. They have worked flawlessly in XP and W7/64 and even with WMCE which is supposed to be a no-no!

So when I got my W7 PC my aim was to buy a pair of AP 192s to get 4 in 4 out with what were reckoned to be excellent new converters (Martin W said so!) I was crushed then to find my new PC had but one PCI slot. Ah well,I wil just wait for the PCIe versions and dropped an E to M-A asking about when. Never was the reply. They are not and will not be upgrading any soundcards to PCIe format, out of MOBO sound altogether.

Bloody outrageaous and commercially stupid IMHO.

Dave.

---

Hi Dave,

PCIe just isn't as popular as USB2 and Firewire, despite all the extra hoops you have to jump through in many cases (controller chips, hidden safety buffers and so on).

This I suspect is largely because laptops have become so much more popular, and USB/Firewire is usable on both these and desktops, whereas PCIe cards have a much smaller market


Martin

--------------------
YewTreeMagic

Hi Martin
Should have explained a bit better, was a half asleep this morning!
I understand what to do with ms, but on that basis, if it is measured in ms, the intervals would be
44, 88, 132, 264, 528
I guess it can be argued that the higher buffers are quite close to 128,256 and 512 samples, but the 44 and 88 are completely in the middle of the 32 / 64 range.
Didn't want to post any numbers that could be determined to be unfair to a units measurements.
Have got a few units that seem to be working this way and wondered what should be the way forward?

--------------------
www.theautobots.com / www.scan.co.uk

Quote Tombot:

---

Didn't want to post any numbers that could be determined to be unfair to a units measurements.
Have got a few units that seem to be working this way and wondered what should be the way forward?

---

Wait until Vin has perfected his real world latency utility, and then you can report the entire round trip latency of any interface, without any jiggery pokery of hidden safety buffers, missing converter latency, onboard SRC latency...


Martin

--------------------
YewTreeMagic

Vin - If you've got code at a beta stage then errr... we'll apply for beta testing positions.

Can't have our Tom sitting around idle in his hovel

--------------------
ScanProAudio & 3XS Audio Systems
ScanProAudio Blog

Hey All,

@ Tom & Pete at Scan, no problem for you guys to test the utility in its current state, it is actually quite usable.

I'll contact you via email... :-)

Re the in between buffer settings , yeh that will be a tougher one to try and do head to head comparatives. I also had similar odd buffer sizes from the SSL Nucleus USB2 interface , but they were actually listed as Samples - 066/132/265/529 , judging by your upper 3 settings, I suspect it maybe the same OEM controller.

Maybe we can use the upper 3 as a cross reference against the Focusrite FW line , that will give us an idea.

Out of interest what values do Cubase/Reaper report for those respective latency settings ?

@ Dave,

As much as it disappoints me I can understand why most manufacturers will not develop PCIe interfaces , as I have noted in the past and Martin has just reiterated, its far easier for them to develop FW and USB2 interfaces to be able to cater for both the desktop and mobile markets. M-Audio are not the only manufacturers who have bypassed development on PCIe, Lynx who in the past have been on the top of the pile in regards to LLP with their Lynx 2 range haven't made the move to PCIe past the AES card either. Maybe with PCI no longer being native on the Intel chipsets , we may see some added incentive for more Lynx PCIe cards .., I can hope.. :-)

So I do understand the difficulty faced by a lot of manufacturers as its definitely a different market landscape and it wouldn't be a problem if we didn't have to navigate the current minefield of the inconsistency of the OEM controllers / drivers. Now some may say its more the fault of the controllers ( Dice ) being used, and the manufacturers can only play with the hand they are dealt. When I first started this endeavour I was also one under that impression, but the fact is this , all the current manufacturers have access to the same line of Dice chips , AVID / M-Audio perform exceptionally well , Focusrite, Presonus, etc do not , it can't be so easily dismissed that is purely the controller , the onus has to come back to the manufacturers doing more than simply supplying the units with the base OEM ASIO driver.

V:

--------------------
AAVIM Technology
DAWbench.com

I had the same problem.

Hi Martin.
PCIe "just isn't as popular" because there just isn't any! ("No call for size 13's sir, you're the 11th person to ask today!)

I am a total pc numpty but maybe someone could tell me if it would been a big problem to have just transplanted an AP192 as is, onto a PCIe PCB?

Then: There are PCIe to PCI converter boards but the sellers don't know if they will work with PCIe soundcards and M-A won't test and tell. Something SoS might look into?

Dave.

Hey All,

Here are the latest results with some added interfaces, a new baseline and amended ratings.





Notes -

First off we have a new Baseline Interface - RME HDSPe AES : ADI8-QS - results across the 3 respective benchmarks were identical to the previous baseline AIO card , proving that the performance of the driver is consistent across the HDSP/HDSPe line. The I/O and RTL was significantly lower due to the tighter AD/DA. A few points, the reported I/O values in Cubase were sans the AD/DA , ( common amongst interfaces when using AD/DA connected via standard AES ), I calculated the added latencies with my RTL Utility which reported an extra 28 samples across the board - 14 samples respectively for the AD/DA ( RME spec is listed as 12 ). The RTL Values are including the AD/DA and all other interface RTL ratios have been amended.

MOTU 424 : 24 I/O - I discovered was not reporting the AD/DA , so the correct RTL was calculated using the Utility and values amended.

LynxTwo C - I was hoping to test a current AES16e and Aurora combo but the loan units didn't eventuate so I dusted off an old PCI Lynx TWO C card to at least get a heads up on the performance of the current driver. Double Playback Buffering has been disabled ( still have no idea why Lynx thought it needed implementing ). The card performed extremely well only being bettered by the 2 PCIe RME units , its a shame that these PCI legacy cards are not suitable for the current Intel chipsets with the non native PCI, hopefully Lynx will eventually update the Lynx TWO line to PCIe as well.

RME Fireface UFX - This was a unit that I know a lot of end users are interested in seeing the results for and I was keen to get it back on the bench after my preliminary experience with a very early unit was less than stellar under FW. In the meantime there has been numerous firmware updates as well as drivers , but I actually used an earlier driver sans the MultiClient option to remain consistent with the earlier Fireface 800 testing. I was pleasantly surprised that the unit under FW had improved measurably to the point of it actually bettering the FF800 results. Thats quite an achievement IMO considering the unit no longer has a dedicated FW controller. USB2 performance was also exceptional , however slightly below the FW results , which may surprise a few people considering the greater focus has been on the USB2 aspect. All in all, a big thumbs up to the RME devs on ironing out the early quirks with the FW on this unit , an exceptional performer on both FW and USB2.

ESI U46 XL - The initial good impression I noted on the preliminary testing changed significantly when I discovered that ESI by reporting the nominal values only, were actually masking large safety buffers as well as double buffering on playback. The calculated RTL via the utility showed significantly higher values than most other interfaces at the respective latencies. RTL % and LLP ratings have been amended and have dropped accordingly. There are also issues with the unit not initialising correctly on current H67/P67 chipsets.

Echo AudioFire 12 - This unit has large safety buffers as well as double buffering on playback to the point that the nominal values reported in the Echo Control Panel are almost comical. I did attempt to get a confirmed reading via my own RTL Utility as well as the Centrance and the results were all over the place unfortunately. My Utility was having issue ithe the excessive safety and double buffering, the Centrance simply refused to give a result. Performance was solid enough but the high I/O and RTL need to be taken into account when weighing up the figures. The excessively high RTL dropped the over all LLP rating substantially, as will be the case with any interface employing large safety and double buffering.

I have also removed some interfaces from the results pending further testing.

I am currently further investigating some of the listed interfaces which I suspect may also not be reporting the AD/DA. Once I have confirmed those results I'll amend the LLP ratings accordingly. Interfaces under investigation - AVID/M-Audio/Focusrite/Midas.

Peace

Vin Curigliano

--------------------
AAVIM Technology
DAWbench.com