Low Latency Performance Of Current Audio Hardware

[Pete Leoni]

The latency thing is the game changer. Round trip latency will soon become the first figure we look at. Almost eveything else is already been dealt with. Near realtime processing is the key to many, many doors. I think we should publish RTL figures for every interface, and encourage the industry to deal with it now.

[LEX]

The latency thing is the game changer. Round trip latency will soon become the first figure we look at. Almost eveything else is already been dealt with. Near realtime processing is the key to many, many doors. I think we should publish RTL figures for every interface, and encourage the industry to deal with it now.

Great Idea. Is it the same for every system? What is the latency on a Mac Pro vs a i7 PC system?

Vin?

LEX

[Pete Leoni]

It will have to be a given that the computer the DAW is based on will have to be able to handle the load, regardless of platform. Running @ near real-time on an older platform or a system crippled by non responsive hardware or software is automatically pointless, whether PC or Mac.
A fast machine is a given!

It should boil down to the interface and drivers (automatically assuming they are un-crippled by any non-real-time hardware, whether this be network devices or "legacy" DSP cards.)

No hardware device in a DAW built today should be allowed to interfere with real time latency at all, including audio interfaces that do not have properly written drivers.

In this day and age that is simply not acceptable. I'm saying that that simple Round Trip Latency figure should become the first yardstick we measure a DAWs performance by, and machines should be spec'd accordingly.

[LEX]

It will have to be a given that the computer the DAW is based on will have to be able to handle the load, regardless of platform. Running @ near real-time on an older platform or a system crippled by non responsive hardware or software is automatically pointless, whether PC or Mac.

It should boil down to the interface and drivers (automatically assuming they are un-crippled by any non-real-time hardware, whether this be network devices or "legacy" DSP cards.)

No hardware device in a DAW built today should be allowed to interfere with real time latency at all, including audio interfaces that do not have properly written drivers.

In this day and age that is simply not acceptable. I'm saying that that simple Round Trip Latency figure should become the first yardstick we measure a DAWs performance by, and machines should be spec'd accordingly.

Well, as it is Pro Tools is really the only thing out there that has the lowest latency.

LEX

[Pete Leoni]

Pro Tools is not native, not really. We are seeking to eliminate hardware. Anything 5ms or less RTL can be considered RT.

[LEX]

Pro Tools is not native, not really. We are seeking to eliminate hardware. Anything 5ms or less RTL can be considered RT.

Sorry, yes PT isn' native. But sample accurate is what makes PT king when it comes to Post.

But, we need a direct comparison with MAC and PC,
LEX

[Pete Leoni]

We really don't need a comparison there (Pc vs, Mac), we simply need *all* platforms to conform to our RTL standards. <5ms RTL under a decent load is all that is needed.

[TAFKAT]

We really don't need a comparison there (Pc vs, Mac), we simply need *all* platforms to conform to our RTL standards. <5ms RTL under a decent load is all that is needed.

I disagree,

All the test should be done cross platform , as the 2 platforms are nowhere near comparable in performance.

There are inherent differences in how ASIO and Core Audio processes are arbitrated at low latency , Core Audio makes 2 to 3 times the calls per sample than ASIO, so it will not achieve the same performance at low latency .

That is clearly indicated by the huge performance variables in not only our incremental DAWbench DSP and Cubendo DSP tests , but also in the 48K and 96K Real World Sessions we developed and used to do our cross platform scaling tests.

The other things that needs to be noted with the RTL testing will be that its becoming more and more common for the audio devs to pad out the playback latency way above the input latency. Lynx was one of the devs that went that route, much to my disappointment, but have recently released a driver where the added buffering is optional.

Also , we need to be able to accurately measure the actual latency , not what the respective control applets for the specific cards are listing, one way is using the Centrance Latency Tool (http://centrance.com/products/ltu/) and then compare that to the reported latencies in Cubendo, which I have found to be pretty accurate actually. However that doesn't help us on OSX tho, so we will need to reply on the latency reported by Cubendo.

BTW: There is an existing thread in The Test Bench area specifically for testing of audio cards , which I was planning on getting a start on over the X-Mas break.

:009:

[nikki-k]

Well, as it is Pro Tools is really the only thing out there that has the lowest latency.

LEX
Apogee AD16x, DA16x... lower latency than PT HD w/ Digi192.
PT HD w/ Apogee. lower still.

Any DAW @ 32 samples with Apogee is lower than PT HD w/ Digi192.

When Apogee released them, it was the *final* stroke.. leveled the playing field in the latency game. Sort of... with the PT HD w/ Apogee solution providing lower latency still. But, if that 32 samples (be it @ 44.1k or 96k or whatever..) is not a negligible amount of additional latency.. well.. lol...

I won't go all diatribe and babble-on... I used to love PT and all the benefits. But, IMO, Avidesign decided to play a dangerous game, and are losing many hands. The big argument in return being that even with native breaking the latency barrier, the great unknown of available resources in nativeland becomes the new game. Of course, many will counter that native power is so high, this is no longer a true concern either. I am a realist tho, and realize too well that it is indeed one.

Sorry for the detour and diatribe I said I would not post.. :(

[Pete Leoni]

That we use the Centrance tool is a given, and that we test all platforms is a given, The figures shown by the apps mean absolutely zilch! What I was trying to avoid is the old Mac vs PC stuff. Of course we need to test them all, if one platform is not capable of real time RTL, that is a reason *NOT* to use it at all! So we are not in disagreement whatsoever. All tests must be made analog out to analog in using the Centrance tool. Guys, we can make a real difference here, and stop this latency insanity!

I can't imagine why we have tolerated it for so long. I do consulting work from time to time for one of the makers, these guys are my friends. I remember seeing my friends eyes glaze over when I explained to him that the current drivers latency issue was going to bite them in the butt. It did. The devices latency was cut in half with a second party driver! This kind of thing needs to stop and we can drive that campaign.

[TAFKAT]

Hey Pete,

We have all been tippy toeing around the whole MAC v PC minefield for too long in my opinion , simply because of the majority of the debates spiral into these cyclic almost quasi religious shite fights due to the subjectivity and ignorance of the combatants. However I have approached it this year in a very objective manner armed with quantifiable data that anyone can roll their sleeves up and qualify , and apart from some minor odd fanboi mind farts over at Gearsluts in regards to , gasp, running OSx86 Snow Leopard configs, has proved to me that the subject matter can be navigated without it descending into the usual free for all.

I have a whole host of Win7 v OSX shootout reports in the works with a few crossplatform DAW apps , Cubendo, Protools LE ( once they get their Win7 and Snow Leopard version public ) , and for those that can't deal with the fact that the performance isn't comparable across platform, well then thats their glitch.. :wink:

If you haven't seen the threads that cover a lot of the results so far, they are Here (http://cubendo.com/showthread.php?t=241) and Here (http://www.gearslutz.com/board/music-computers/419579-i7-nehalem-hyperthreading-daw-performance.html)

RE Putting the audio hardware devs on notice that we are going to be watching closely , I pretty much have been for years indirectly but was planning on doing it more so with the new interface testing initiative that I started a few weeks back, so we are definitely on the same page. I have already had one dev listen to my concerns that their doubling of the playback buffer on a recent driver build was very disappointing after all of the work I had done over the years supporting their low latency performance. The new version makes it optional, so we already have their attention , and the new initiative will report as the chips fall , warts and all, for all to see.

I have had a journalist friend of mine state that I am either brave or stupid to attempt the new reports, I agreed I am probably both... LOL

[fishtank]

Apogee AD16x, DA16x... lower latency than PT HD w/ Digi192.
PT HD w/ Apogee. lower still.

Any DAW @ 32 samples with Apogee is lower than PT HD w/ Digi192.



You beat me to it!

You don't have to use Apogee converters to beat or at least equal the latency of PT HD. A DAW running @ 32 samples with any reasonably low latency set of converters will get you there.

I'm already doing this most of the time with my current (not so powerful) system. I'm extremely excited to build an i7 (that will eventually be swapped out for an i9) system, as the performance is far better @ 32 samples.

[Pete Leoni]

Just be aware that any latency measurement not done analog out to analog in with the Centrance tool is very likely to be wildly erroneous.

[Pete Leoni]

Anything less than 5ms round trip can certainly be classified as real time for audio. No need to compare to analog. Analog latency? Ever work on a real piano? (-:

[fishtank]

Just be aware that any latency measurement not done analog out to analog in with the Centrance tool is very likely to be wildly erroneous.


I ran the Centrance tool with a 32 sample buffer setting on my RME RayDAT and got pretty much exactly the results I expected - 165 samples / 3.74 ms (@ 44.1K). This was using my old Frontier Design Tango 24 converters that are temporarily out of retirement as my SSL Alphalink is lost somewhere in the warranty repair black hole across the pond. :icon_mad:

My Crane Song HEDD 192 measured 191 samples - a bit more converter latency as I expected and was already aware of. The only converter I have that I know the exact A/D and D/A latency in samples is my SSL - I'll verify that whenever SSL finally decides to get me a unit back (it is a bit more than the Tango 24, but less than the HEDD 192 IIRC).

The numbers make sense to me: RME is 96 samples (32 x 2 plus the extra 32 on the input side) plus the converter D/A and A/D latency. I believe PT HD is somewhere around 200 samples.

Pete - I'm curious as to why you thought my numbers would be erroneous?

[Pete Leoni]

No, those sound right to me. RME are the good guys in this latency issue!

[nikki-k]

Just ran this on my MR816 w/ CEntrance... 32 sample @ 44.1k: 153 samples, 3.47ms.

[TAFKAT]

Nikki and Fishtank,

Just out of interest , what was Cubendo reporting back compared to the Centrance tool ?

List the reported In / Out figures, Thanks.

Those MR816 figures being better than the RME/ various ADDA numbers is interesting , but I doubt the scaling performance would be comparable at those latencies.

[nikki-k]

Yeah, scaling favors RME big time. I tried the Cubendo test at 32 and 64 samples, 24/44.1k, and I got lower numbers than reported for RME based scaling graphs...
32 samples: at 51 enabled, thought I heard a fizzle. At 53, definitely heard one every so often.

64 samples: At 104, thought I heard one. At 108, definitely got them.
HT on, EIST, C1, Cx, etc disabled in BIOS, no other tweaks to W7x64 retail or BIOS (yet?), so tweaks might be a factor, or my own error? lol..

Ran that Centrance utility multiple times, same results every time. Attached screens of MR816 panel and C5 device setup..

[TAFKAT]

Hey Nikki,

Thanks for that .

At least the MR setting panel and Cubendo are reporting the same thing

We do need to clarify what the Centrance tools is reporting back as round trip latency in correlation to the Cubendo / MR readout. Its not making any sense to me atm.

Just the MR playback latency is higher than what the Centrance is reporting as RT, unless the Centrance reading is digital and bypasses the AD/DA.

Did you do it digitally or via analog ?

Re the scaling, not overly surprising to be honest. I'll do some head to head with a FF800 when I get a few minutes so we can have a better comparison with just FW interfaces.

P.S: We do need to move this discussion to its own thread, continue here for now until I get some time to tag the relevent posts and copy them to a new thread.

:009:

[nikki-k]

Cool on copy ->new thread :D Was wondering as it got so far OT

I already had a TS/mono guitar cable plugged into mic/line 1, so I simply popped the free end into my patchbay, effectively rerouting the output of chan 1 to the cable (instead of the Blue Sky monitoring system). All in all, about 4-5 meters of cable between analog out 1 and analog in 1 (line input, front).

Nice to be sub 4ms with a native system these days. Even nicer to be able to work at 32 or 64 samples with a pretty good sized song goin. Still, I really miss working with tape and a nice desk some days. For composing though... hehehe..

[TAFKAT]

Hey Nikki,

Wow, thats some pretty impressive low latency AD/DA numbers on the MR, if only they could get that into a PCIe driven interface.

Still doesn't correlate to the numbers reported by Cubase , and from memory they used to be really close between the Centrance and the reported figures the last time I had a play with the Centrance tool a few years back.

I'll be really interested in to see what Fishtanks numbers are like in Cubendo.

[nikki-k]

Yeah, would definitely love to see some other MR816 figures so I can see if it holds. I was shocked when the numbers popped, hence rerunning it.

To me, these numbers plus the scaling... HUGE wake-up, as it only shows that the two do not go hand in hand (necessarily). IMO, the MR816 converters are pretty sweet, especially for the price. My only bitch is that there is not a way to absolutely be sure of a complete defeat of the pre's (that I know of? utilizing insert returns on 1 & 2 is a no go IMO.. but very close). The RME stuff scales well, with slightly higher base figures (via Centrance?). But, I would love to do a dedicated, properly tweaked W7x64 install with the friendliest BIOS settings (EIST and C1, Cx, etc disabled all the BIOS tweaks needed? RAM is reporting and auto-set properly from what I see) to *properly* test scaling for my MR816 and C5. Biggest problem with my W7x64 right now is the bashing Avidesign goodies have done to it... have not had time to do a proper restore from disk image.. and not sure if the release of PT 8.0.3 and the "beta" drivers have had/will have any adverse effect(s). IMO, that stuff is still piecemeal BS, full of spare parts and "coding duct tape." LOL!

Just curious... has anyone come up with a comparable scaling test session for PT (HD, LE, MP)? I tried to find some way to do this between Cubase, Logic, Digital Performer and PT (and wanted to ad Reaper), but found that since each app utilizes different "tricks" to.. well, exist even, utilizing a single plug-in across apps was not considered "comparable." Since VI's seemed to present a (semi) unique scenario in use, I tried to find a cross-plat, cross-app VI that would provide this, but every one I asked about got shot down for one reason or another. Almost every one was rejected due to the inability for RTAS and Core Audio and VST to even be considered comparable, and then the inclusion of Logic at any buffer except 1024 or 2048 was shot down due to Logic's *unique* buffer "tricks." Now that I am solely using W7x64, Logic and DP are out for me... and PT is still.. "broken."

[TAFKAT]

Just curious... has anyone come up with a comparable scaling test session for PT (HD, LE, MP)? I tried to find some way to do this between Cubase, Logic, Digital Performer and PT (and wanted to ad Reaper), but found that since each app utilizes different "tricks" to.. well, exist even, utilizing a single plug-in across apps was not considered "comparable." Since VI's seemed to present a (semi) unique scenario in use, I tried to find a cross-plat, cross-app VI that would provide this, but every one I asked about got shot down for one reason or another. Almost every one was rejected due to the inability for RTAS and Core Audio and VST to even be considered comparable, and then the inclusion of Logic at any buffer except 1024 or 2048 was shot down due to Logic's *unique* buffer "tricks." Now that I am solely using W7x64, Logic and DP are out for me... and PT is still.. "broken."

Already well in the works.

I have a DAWbench DSP session for PT8 using the internal Digiverb , that was for Win7 v OSX cross platform scaling tests only, but I will have a MD5 version as well shortly, just need to find some time to configure the session.

I hate the fact that PT does not have track presets, or a simple way to duplicate the insert settings, I have had a few suggestions but they are all a bit of run around. I will get to it tho.

With the MD5 version we can then do shootouts between RTAS/AU/VST/OSX /Win7, I was also going to do MAS, but I am not sure how many DP users would be even interested.. LOL

Applications that will be included in the next round of shootouts with DAWbench DSP MD5 sessions will be , Cubendo, Reaper, SONAR, Logic 9, StudioOne , and I will report warts and all. With the MD5 being native VST/AU and RTAS, its a good leveller.

Logic is also a bit of an odd ball, as the default playback latency is 1024, no matter what the input latency setting, and despite being told that it does revert back to the set latency setting under monitoring or track arm, I do not believe thats the case, it simply shifts the armed track to a lower latency mode, playback is still at 1024.

Re the Universal VI test, I have been talking about one for years now, just never got around to doing it, and its a bit tougher to knock together one that will be easily accessible. I'll have another look see next year. I already have a VI Benching methodology/template in place based on my L-Factor benchmark from a few years back, we just need to decide on a VI list.

:009:

[Jcschild]

Hey Vin,
we are about to dev a test using Vienna. if you are anywhere near close to a samples test i would rather use yours so we are all using the same tests.
our old test is too limited. thought about Komplete 6 as well..
we have every Vienna library so we thought we could load up at least 12 gig test :icon_eek3:
that would be rather hard with Komplete.

Scott

[Daryl]

Hey Vin,
we are about to dev a test using Vienna. if you are anywhere near close to a samples test i would rather use yours so we are all using the same tests.
our old test is too limited. thought about Komplete 6 as well..
we have every Vienna library so we thought we could load up at least 12 gig test :icon_eek3:
that would be rather hard with Komplete.

Scott
Scott, I would really recommend doing the test with VE Pro, as then you could also test 64bit on OSX, which you can't do with the Vienna Ensemble 2.

FWIW my template is around 24GB. Would you like a copy of the Metaframe?

D

[Jcschild]

Hey Daryl,

yeah we intended to use Ensemble Pro.

while 95% of people wont be able to duplicate our tests
its really not much of a concern for me anymore.
i am more interested and showing the memory bandwidth strengths between systems.
particularly MacPro, and PC X58 and P55 systems.

unlike Vin i put a lot of favor on DDR3 1600 and low CL ratings vs say Apples 1066.
also dual vs triple channel.

[TAFKAT]

Hey Vin,
we are about to dev a test using Vienna. if you are anywhere near close to a samples test i would rather use yours so we are all using the same tests.
our old test is too limited. thought about Komplete 6 as well..
we have every Vienna library so we thought we could load up at least 12 gig test :icon_eek3:
that would be rather hard with Komplete.

Scott

Scott,

Use the L-Factor II session and methodology as your template, thats what the DAWbench DSP Universal will be based on if/when I can ever get my shite together.

The short music piece was written for me by a close friend here in Melbourne who is an orchestral composer , so it will suit well for orchestral sample libraries.

I cobbled together some quick sounds programmed in the older A1 in the original template, but they are all,clearly labelled as to what instrument they are supposed to be.. :wink:

That session will progressively load ASIO and Memory resources, and will quickly sort the chaff from the wheat.

So we can use your test as the monster sample based one, and I'll still cobble together a smaller one using the best freeware/demo VI's as I can for the masses.

Open to suggestions for VI's there.

:009:

[TAFKAT]

[QUOTE=Jcschild
unlike Vin i put a lot of favor on DDR3 1600 and low CL ratings vs say Apples 1066.

also dual vs triple channel.[/QUOTE]

Watch yoo on about Willis ... ?

Well I don't dabble with selling overclocked units, thats your party, I don't want to crash it.... :eusa_whistle:

Seriously tho, I'll be interested what the performance variables are with the samplers, there is SFA in the x-scaling results.

[Daryl]

unlike Vin i put a lot of favor on DDR3 1600 and low CL ratings vs say Apples 1066.
also dual vs triple channel.
I don't have a dual quad i7 (whatever those darned Xeons are called these days), but I do know that VSL has been saying that in their tests for MIR, speed of RAM has played a part. I'm still undecided whether or not to jump into the current generation of machines, or wait for the dual 6 core ones. I guess that sooner or later I'll need to make the jump, so I'll have to see what is available at that time. Why is it never time to say "enough is enough", when it comes to these ridiculous machines?

D

[Jcschild]

unlike Vin i put a lot of favor on DDR3 1600 and low CL ratings vs say Apples 1066.

also dual vs triple channel.

Watch yoo on about Willis ... ?

Well I don't dabble with selling overclocked units, thats your party, I don't want to crash it.... :.

even when not over clocking the CPU, all our systems (i7) ship @ 6.4 QPI 1600 fsb memory
starting to ship the 750 that way as well :D but thats overclocked to 3.2.
:icon_eek3: i cant leave crap alone man.... got to tweak....

[Bman]

RE Putting the audio hardware devs on notice that we are going to be watching closely , I pretty much have been for years indirectly but was planning on doing it more so with the new interface testing initiative that I started a few weeks back, so we are definitely on the same page. I have already had one dev listen to my concerns that their doubling of the playback buffer on a recent driver build was very disappointing after all of the work I had done over the years supporting their low latency performance. The new version makes it optional, so we already have their attention , and the new initiative will report as the chips fall , warts and all, for all to see.


Thanks for this heads up Vin (and your persistance with this particular dev). Downloaded and much happier with this driver.

Cheers

Brett