• Hardware
  • Test results on a Reaper forum - seem inaccurate to me
2017/06/04 21:08:19
Cactus Music
The results are found here, not sure if they took all results and averaged them as many submitted for the same interfaces. Prety unscientific test eh..  Just made me think we could do something like it here. 
http://www.kailuamusicschool.com/tech/round-trip-latency-roundup/
 
This is the GS thread. Steveo42 posted the link in another thread so I found myself reading most of it out of curiosity. Problem I have with it is it shows pretty similar results for most interfaces which blows the doors off the "buy a RME for low latency" quote we often read on forums.   http://forum.cockos.com/showthread.php?t=174445&page=4
 
 
I think to make it more scientific and easier to read we would need a baseline of only a few settings. 
Like there's no point comparing a digital loopback to analog.  
And stick to one clock rate like 48 hz as we all understand it makes the figures go down a little as you go up. 
I'd think if we just did all at 48hz and only 32, 64, 128 and 256  that would give enough info 
And we could use Sonars report or this tool  http://www.oblique-audio.com/free/rtlutility
 
Anybody interested or should we just use asio4all and be done with it! :)
 
2017/06/05 08:01:22
Rob[at]Sound-Rehab
If you want to do this accurately, you need to do the loop back, record the transient, split the clip at the transient, read the length in samples and convert to ms because tools like Sonar's reported RTL not always give you correct results e.g. in case with the latest MOTU AVB it misses 82 samples (independent of sample rate) which the unit needs to do its internal DSP stuff ... still RTLs obtained are lower than what is listed in above threads

BTW I have the MOTU measurements and I believe I also posted them in some thread about a year ago.
2017/06/05 15:25:03
Cactus Music
Well this is just it, seems these figures are all over the map. 
2017/06/05 16:47:45
mettelus
Didn't we do a chunk of this in that loopback thread a year or so ago? Some units did seem optimized at specific sample rates, but a lot of data was started in that thread too (on a cell, so will never find it).
2017/06/05 17:48:57
bitflipper
Whoever did those tests should have looked at the results and immediately asked himself "what am I doing wrong?".
 
That there are variances is not at all surprising. Hardware-wise, the differences won't be huge (e.g. 0.5 ms best-case vs. 2 ms worst-case), but drivers can exhibit greater or lesser efficiencies. That's the case with any two pieces of software that do the exact same thing. It comes down to how much effort the coders put into optimization. That said, a nearly 2:1 variance seems to more likely reflect an error in methodology.
2017/06/05 17:56:39
azslow3
Cactus Music
The results are found here, not sure if they took all results and averaged them as many submitted for the same interfaces. Prety unscientific test eh..  Just made me think we could do something like it here. 
http://www.kailuamusicschool.com/tech/round-trip-latency-roundup/
 
This is the GS thread. Steveo42 posted the link in another thread so I found myself reading most of it out of curiosity. Problem I have with it is it shows pretty similar results for most interfaces which blows the doors off the "buy a RME for low latency" quote we often read on forums.   http://forum.cockos.com/showthread.php?t=174445&page=4
 
 
I think to make it more scientific and easier to read we would need a baseline of only a few settings. 
Like there's no point comparing a digital loopback to analog.  
And stick to one clock rate like 48 hz as we all understand it makes the figures go down a little as you go up. 
I'd think if we just did all at 48hz and only 32, 64, 128 and 256  that would give enough info 
And we could use Sonars report or this tool  http://www.oblique-audio.com/free/rtlutility
 
Anybody interested or should we just use asio4all and be done with it! :)

From what I have observed in the Internet before that table look accurate. RTL for Interface/Driver version/Frequency/Bit depth/Buffer size is a constant. Particular computer should not influence it at all. So one single measurement (assuming done with real loopback test) is scientific.
 
Sonar reported latency is not scientific. It trust the information provided by the interface. Some of them do not report truth.
RTLUtility is a "hardware prove". That result you can trust (at least one "small man" DAW has such thing build in, easy to use and accurate by definition for any interface/mode/driver/etc.)
 
The problem, all that RTL numbers say nothing about which column is usable, especially not for particular system. Here statistic is required, so for which users/interface combination particular buffer size has no problem. Unfortunately that is all aspects dependent, from hardware up to VSTs in use. And that is the reason for "buy a RME for low latency" quote. Most users have confirmed so far that IF particular system CAN run with 64 samples buffer, THEN RME can be used with 64 samples. Reversed, if RME can not work with 64 samples NO OTHER INTERFACE (with the same bus type) can work with 64 samples on that system/environment (I have not seen any single report breaking that statement). It can happened some other interfaces can be used with the same settings as well, but they can not go lower, so they are just "not worse". I must admit that Internet claim modern MOTU and ZOOM are comparable in terms of stability and RTL. But that can be proved by time only (and taking the number of reports about broken MOTU units, it can take quite some time).
 
I do not have "hi end" interfaces, but I have observed that I can not use my VS-20 with the same buffer size as my M-Audio, on physically and in software the same system. Especially on low end, manufacturers not only return garbage about latency but also allow setting which then know can not be used in practice.
 
Users see 1ms in advertisement, see 5ms in software (wonder why... but then read small text in advertisement...) and looking that other work with over 10ms, think they are working with the best interface in the world. Not many then start RTL, but if they do, they set 64 samples and that returns 16ms "something is wrong here, bug Internet claims that is still not so bad for my purpose". When DAW is constantly crashing with 64, they tend to blame computer/software, set it to 128/256 and live with that.
It can happened the same user could happily use RME with 64sample and 6ms RTL. So people recommend to try. Sound logical for me.
 
 
2017/06/05 19:02:54
Soundwise
Low latency is overrated. Since I started using outboard gear for direct monitoring, latency has become unimportant.
2017/06/05 19:31:47
Cactus Music
It ( RTL)  only matters when playing live VST's and using in the box guitar sims. My usable RTL as reported by both the RTL loopback and Sonar is the same @ 6.5 ms for both my Tascam and my Scarlett. And these figures do not change enough to matter when I use different computers be it W7 or W10. I experience no latency issues unless I have certain plug ins active which we all understand very clearly why this happens. 
The reason I'm curious is my plan was to purchase a Motu for live playback based on people stating better RTL performance. Those test results show I would not gain anything but I figure that is not true. 
2017/06/05 22:07:51
mettelus
Soundwise
Low latency is overrated.




I tend to adhere to this camp as well, and think a good part of it is people being able to adapt (or not) to their environment. I run amp sims through a PA quite a bit, and the speakers are 18' away (18' / 1.125'/ms) = 16ms from PA speaker placement alone).
 
Taken to even more extremes... you do not see orchestras huddled into a space the size of a car, or see a violinist stop off stage because they cannot sync to the tuba. If people cannot readily adapt to their environment, church hymns would have been a done deal eons ago.
2017/06/06 02:44:41
steveo42
Wrong thread. Sorry.
 
 
 
 
 
 
12
© 2024 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account