robinv wrote:ef37a wrote:
Used the latest drivers and firmware updates? Or are we both confused now?
Dave.
I'm sure he has - the guy was asking for an opinion, there's nothing to be confused about![]()
Oooo! Old, meds, easily done I assure you!
Dave.
robinv wrote:ef37a wrote:
Used the latest drivers and firmware updates? Or are we both confused now?
Dave.
I'm sure he has - the guy was asking for an opinion, there's nothing to be confused about![]()
alexis wrote:
Thanks - just wondering, since the UR28M is listed as having driver 1.1.1 on the page you linked to, would those results not necessarily be applicable to the latest driver?
One question on your last column if I could - some of the RTL columns have a double " ** ", with the comment "RTL calculated via utility". What does that mean, as opposed to RTL being calculated in a different fashion?
I guess in a practical sense, for my UR28M - the numbers in your column are greater than my old Delta 44 card reported in its control panel ... 10 years ago! Do the RTL numbers in your last column reflect the "real-world" latency, regardless of what the UR28M's control panel reports?
And if I'm recording/tracking using "direct monitoring" does the actual latency become unimportant? (Or maybe it is still very important? ... For example if another application like UAD-2 looks to Cubase's Control Panel to perform latency compensation, but it is reported by Cubase incorrectly as determined by your testing, and so things go awry?)
TAFKAT wrote:alexis wrote:
Thanks - just wondering, since the UR28M is listed as having driver 1.1.1 on the page you linked to, would those results not necessarily be applicable to the latest driver?
Any driver 1.1.1 or above will have the improved performance.One question on your last column if I could - some of the RTL columns have a double " ** ", with the comment "RTL calculated via utility". What does that mean, as opposed to RTL being calculated in a different fashion?
Some of the results are from pre the RTL Utility, those sans the RTL calculation also include the AD/DA in the I/O values , so the measured RTL would be very close , but I will amend what units I still have access to on the next update.I guess in a practical sense, for my UR28M - the numbers in your column are greater than my old Delta 44 card reported in its control panel ... 10 years ago! Do the RTL numbers in your last column reflect the "real-world" latency, regardless of what the UR28M's control panel reports?
Can't remember that far back, sorry. The Delta may have been reporting Nominal figures back then, if so, they will have no correlation to what was actually delivered.And if I'm recording/tracking using "direct monitoring" does the actual latency become unimportant? (Or maybe it is still very important? ... For example if another application like UAD-2 looks to Cubase's Control Panel to perform latency compensation, but it is reported by Cubase incorrectly as determined by your testing, and so things go awry?)
Direct monitoring is AD/DA + DSP/FPGA , so if you are recording dry, buffers are unimportant to that recording environment, but you cannot monitor FX. If there is a large variance between what is reported and actually delivered, it can interfere with Plugin Delay Compensation , most DAW's have a way of dialling in th values of the AD/DA if need be, but if there are hidden buffers not being reported , its more difficult. Most don't bother with the AD/DA values as they pretty small.
V.C
TAFKAT wrote:Just blowing the some cobwebs to let you guys know I am still alive and kicking on this project
table for two wrote:
Lego 20min55 made me smile![]()
Nick Park stylee
Users browsing this forum: No registered users