Metric Halo Discussion Forum
The place to talk MH!

Home   Search      Help    Register    Login
Home » Software » SpectraFoo » Transfer Function Instrument - Latency Management (Understanding and managing your signal path latency between SOURCE and RESPONSE)
Transfer Function Instrument - Latency Management [message #86130] Sat, 09 August 2014 01:43 Go to next message
rabyn is currently offline  rabyn
Messages: 27
Registered: July 2014
Location: Planet Earth
Junior Member
In a previous post, I provided information about using the internal signal generator loop function of SpectraFoo Complete to avoid using a physical OUT/IN jumper cable. There is already a caution about the downside of doing this in that post but in reading over it again, I realized there might be room for a bit more explanation for those who have yet to grasp the concept.

IF you use the internal loop function, you're bypassing the DAD circuitry (digital/analog/digital) for the SOURCE signal. The SOURCE signal becomes a virtual signal path and never leaves the box. This may or may not be a problem. The only way to know for sure if there is a problem is to understand the implications of making this signal path choice.

One of the habits I have adopted is to "verify" my audio interface before I begin to take more complex measurements.

A simple measurement that is somewhat trivial in nature but relevant for making sure your signal routing is correct is to measure a virtual signal against a parallel virtual signal. When doing so, logic would suggest that you should get a COMPUTE DELAY result of (0ms) between the signals & a perfect frequency and phase response (straight green lines on the 0db indication line). If not, something is different inside the box. Assuming you're using a Metric Halo audio interface and Mio Console for FW routing, this could be easily achieved if you have a plugin on one of the DAW channels and not the other. In fact, I have played virtually by added a delay or EQ plugin to the SOURCE but not the RESPONSE, RESPONSE but not SOURCE to see what the result is. For audio interfaces with onboard DSP, you can learn the basics without ever leaving the box.

Once you have a verified "virtual" rig, the next measurement you might make is a virtual SOURCE signal against a physical OUT/IN loop RESPONSE. This measurement will reveal the latency of the device (which is good to know) as well as the frequency and phase response of the DAD circuitry. When performing this measurement typically one can expect to see a sharp drop in HF content related to the selected sample rate and some phase and frequency drift on the LF side of the windows.

Once you have verified that your audio interface has "relatively" perfect frequency and phase response and you know what the round trip latency of the audio I/O is (by taking a virtual SOURCE to physical RESPONSE measurement), you might use the virtual signal loop as your SOURCE signal again as long as you remember that there is a latency difference between that SOURCE signal and the RESPONSE signal. This latency discrepancy between signals isn't a big deal as long as every measurement you take uses the same exact setup. If you're constantly changing your SOURCE and RESPONSE points between multiple inputs and outputs, you might be best off avoiding a virtual loop as a SOURCE signal. It depends on whether that causes you problems or not.

If you still can't wrap your head around the virtual loop concept, just use a physical loop out and in. This way your SOURCE and RESPONSE both include the same DAD circuitry and latency. In this case, even an inferior audio interface disappears from the measurement because it's common to both signal paths.

One more point I'll make.

If you're feeding pink noise through a digital console and splitting the console output signal in order to feed a SOURCE signal back to the audio I/O, you're adding latency to the SOURCE side of the measurement process that isn't part of the RESPONSE signal (assuming the mic signal goes straight to the audio I/O) which can lead to confusion.

The goal (in my view) is to get to the point where you know and understand your rig and the transfer function instrument inside and out. This is best achieved in private when you have lots of time to experiment and make mistakes.

Understanding the signal path (and any latency involved) of both SOURCE and RESPONSE signals is vital for making successful measurements.


ra byn (robin)
Re: Transfer Function Instrument - Latency Management [message #86131 is a reply to message #86130] Fri, 15 August 2014 16:45 Go to previous message
rabyn is currently offline  rabyn
Messages: 27
Registered: July 2014
Location: Planet Earth
Junior Member
A few screen shots to explain the previous post.

index.php?t=getfile&id=64&private=0

Comparison between internal loop and ULN8 (prior to delay correction)

index.php?t=getfile&id=67&private=0

Comparison between internal loop and ULN8 (after 116 sample / 2.63ms delay correction)

index.php?t=getfile&id=66&private=0

Comparison between ULN8 mic pre 1 and ULN8 mic pre 2 - latency is the same between signals so compute delay shows (0ms)

index.php?t=getfile&id=63&private=0


ra byn (robin)

[Updated on: Fri, 15 August 2014 16:49]

Report message to a moderator

Previous Topic: Command Keys
Next Topic: Testing your Metric Halo hardware
Goto Forum:
  

[ PDF ]

Current Time: Tue Jul 07 21:05:00 EDT 2020