Quote:
Originally Posted by figgebass  yeah, it's 1.6 at 96....
SSL Madi has a latency of 2ms at 44.1 and 0.9 at 96.
However...that's really not the whole picture since they get those numbers from sending pings or recorded AND buffered(Which means that the computer already has done its maths before we hear any sound, hence no latency coming from that process) data out and back in again. |
This is a little misleading. The time to calculate a single sample must be significantly less than a sample time, or you could never actually operate in realtime. Thus there is no need to set aside any more time for this beyond the 32 samples you referred to.
Disk buffering has no impact at all on round-trip latency; it comes into play when you first press the Play button as a small pause (and if the software is smart, it is done *before* you press Play based on the position of the SPL).
Quote:
What is more important is the time it takes to record something into logic that needs to be routed back out again. When I did a test like that the round-trip through logic was 5.3 ms with the SSL. God knows what it would be with the Symphony.... =/
I wonder what times the RME hdspe gets cos I tried that some weeks back and it was pretty fast but the d/a sucked monkeynails through the breakout cable...I was trying a cheap route back then...;-)
|
When I get back to my rig I'll have to pull out my scope and actually measure the analog-to-analog-through-the-whole-swamp path, but it is pretty short. The Symphony card itself has virtually no latency; the majority of it is in the A/D/A conversion process and whatever buffering is happening in the driver to provide a little elasticity. For what it's worth, the ping measurement in the D->A->D direction is less than a millisecond according to the I/O plug.
But you hit the nail on the head--the only latency path we really care about is the A->D->A path while doing software monitoring; the rest doesn't matter, assuming accurate delay compensation.