Dual Channel FFT

Re: Dual Channel FFT

When you are using a dual channel FFT analyzer, SMAART, EASERA, etc... What does the loop-back channel do to improve the measurement over just a single channel measurement?


With a dual channel FFT you can measure frequency and phase response of the speaker system with just music as the source (i.e. while you mix) and it’s somewhat independent of the rooms reverberant influences.
If you are using Lake processing you can overlay the Lake EQ screen and FFT measurement to determine the correction needed.
Lake Processing - SMAART Capture - Room EQ Commissioning Demo - YouTube
 
Re: Dual Channel FFT

When you are using a dual channel FFT analyzer, SMAART, EASERA, etc... What does the loop-back channel do to improve the measurement over just a single channel measurement?

The loopback is htge reference. How would you know what you are measuring-if you didn't know what the signal that you started with looks like?

A single channel has no way of knowing if it is measuring the actual signal or all sorts of other "things"-such as people talking-HVAC-traffic and so forth.
 
Re: Dual Channel FFT

Okay so when using music as the source, or performing some type of differential analysis like, what is the transfer function between point A and point B. I understand those applications.

Lets say I am generating pink noise from my laptop, and trying to measure the transfer function of a speaker, what is the advantage of the loop-back cable then? Why don't I just measure the the transfer function from the actual output I'm using direct to the input I'm actually using? Then use that to correct for any timing, AA filtering, other problems. I already have the data for the pink noise being generated inside the computer.
 
Re: Dual Channel FFT

Hi Mark:

You obviously have a solid grasp on what's going on and your logic is spot-on, but you're missing something simple (one of my specialties).

Mark said:
...Lets say I am generating pink noise from my laptop, and trying to measure the transfer function of a speaker, what is the advantage of the loop-back cable then? Why don't I just measure the the transfer function from the actual output I'm using direct to the input I'm actually using? Then use that to correct for any timing, AA filtering, other problems. I already have the data for the pink noise being generated inside the computer.

Here's the issue - the pink noise stimulus in your computer is slightly different than the pink noise stimulus that you'd measure even with a hardwire loopback of the measurement channel. There is at least one reason for this and possibly two:

1. The pink noise returned to the measurement channel went through D/A and A/D conversion that the internal pink noise did not.
2. Depending on the OS and sound card, every time you start your measurement software the roundtrip latency may change slightly.

Forcing your reference channel pink noise to go through the same D/A, A/D and roundtrip latency will force the measurement to yield the truth, the whole truth and nothing but the truth about the behavior of the DUT. Nevertheless, the difference between an internal reference stimulus and the one that went through the same converters and latency as the measurement channel are typically insignificant for acoustic work.

A final note is that some measurement programs offer companion sound devices that do not bother to route the stimulus through the D/A, A/D stages and yet are able to get at the whole truth. This is because the hardware's behavior is known to the mfg and they account for the changes that occur internally.
 
Re: Dual Channel FFT

Lets say I am generating pink noise from my laptop, and trying to measure the transfer function of a speaker, what is the advantage of the loop-back cable then? Why don't I just measure the the transfer function from the actual output I'm using direct to the input I'm actually using? Then use that to correct for any timing, AA filtering, other problems. I already have the data for the pink noise being generated inside the computer.
Dual channel FFT's make some assumptions regarding the data being fed into it: 1) Both the measurement and reference inputs of whatever interface is being used must treat the individual inputs the same in terms of frequency/phase response, 2) The timing between the two channels must be stable, or synchronous. Get those two assumptions right to begin with, and you're starting down the road towards making valid measurements with a dual channel FFT.

Smaart 7.3 kinda lets you do what I think you're describing with their internal "loopback" feature, however the clocks *must* be synchronous output vs. input, which limits which audio interfaces will work with this feature, and also lengthens the propagation time giving you approximately 40-50 ms additional delay time for the signal to be eventually routed back as "reference" into a measurement engine. This also limits you to using ONE interface to handle ALL inputs and outputs (for the sake of clock synchronization). Nevertheless, Langston raises very valid points about differences in the signal between what the dual channel FFT thinks in "real" and what is "reality." If you want to do the internal loopback feature in Smaart 7.3, then use a very high quality audio interface, and not the cheap built-in sound card on your computer, in addition to clock synchronization, what "goes out" must match what "comes in" in order to make the measurement valid.
 
Last edited:
Re: Dual Channel FFT

Dual channel FFT's make some assumptions regarding the data being fed into it: 1) Both the measurement and reference inputs of whatever interface is being used must treat the individual inputs the same in terms of frequency/phase response, 2) The timing between the two channels must be stable, or synchronous. Get those two assumptions right to begin with, and you're starting down the road towards making valid measurements with a dual channel FFT.

Well I see how this is easily met with COTS products since channel pairs are normally implemented with a stereo ADC.

Smaart 7.3 kinda lets you do what I think you're describing with their internal "loopback" feature, however the clocks *must* be synchronous output vs. input, which limits which audio interfaces will work with this feature, and also lengthens the propagation time giving you approximately 40-50 ms additional delay time for the signal to be eventually routed back as "reference" into a measurement engine.

Strange, the extra propagation delay must be a behavior inherent to Smaart. In fact there should be more usable bandwidth available as the reference is already stored in memory. I don't see how a system designed to work as I described would suffer from extra propagation delay or clock synchronization issues after calibration measurements had been made. (Assuming the hardware is not restarted.) Although, I would agree that Windows or other OS synchronization issues might be a real problem with low-end drivers.

This also limits you to using ONE interface to handle ALL inputs and outputs (for the sake of clock synchronization).

I don't see how a typical dual channel FFT differs in this respect. If you are taking your loopback input off of one interface that tells you nothing about the second interface. If as I proposed in the previous post you took calibration measurements of each input against the output then those would be correct. (At least until you restart the hardware that is; assuming no ref clock or sync pulse between interfaces.)

Nevertheless, Langston raises very valid points about differences in the signal between what the dual channel FFT thinks in "real" and what is "reality."

Would it not be better to make a calibration curve even perhaps from the amplifier output if you are concerned about issues in the signal path?

From Langston Holland's post I believe point (2)
Depending on the OS and sound card, every time you start your measurement software the roundtrip latency may change slightly.
is the most important reason COTS measurement systems are implemented as dual channel FFT. This value can be as high as 100ms on low end hardware which would be bad for any type of transfer function measurement (even a std dev<1ms is not good.) For ASIO I have seen histograms which are close enough to real-time (i.e. hardware designed with ref clock, sync pulse and trigger pulse) for audio work.

I would appreciate any other thoughts on the subject.

Mark DeArman
 
Re: Dual Channel FFT

Mark, even with matched pairs of channels, you still need clock synchronization between input and output, and between multiple interfaces, for your dual channel measurements to be valid. Read that sentence carefully again and again and again until it sticks in your brain. Put together any digital audio system using multiple devices, and you MUST have a word clock master and a bunch of word clock slaves in order for things to cooperate with each other in the digital audio realm. With dual channel measurements it's no different. At present, using only one computer audio interface is a constraint due to differing word clocks between multiple interfaces that are typically designed for a project studio where only one interface is used at any time. If you use multiple interfaces, one needs to be set as the master clock, the rest of them slaved to the master clock, a feature that is not available on most common computer audio interfaces. Yeah, maybe you can mess around with aggregate device managers, or there are exceptions... The new Smaart I/O box has an external clock bus that allows multiple interface boxes to be synchronized, same with the Systune Aubion interface box, and maybe the high end RME stuff and the Roland Octacapture, but everything else is a crap shoot for synchronization.

You are also making a lot of ASSumptions on what goes on behind the scenes, the majority of the delay with an internal loopback signal is due to the ASIO or CoreAudio drivers and how the computer audio interface interacts with those drivers, not Smaart itself. I'm not a programmer, nor did I stay at a Holiday Inn Express last night, but you can probably glean some insight in this thread, maybe converse with an experienced programmer like Adam about this:
new to both USBPre2 and SMAART7

With regards to calibration curves, how would you go about making these without a reference to refer to? In this situation, kinda the chicken before the egg scenario. Why make things more complicated than they need to be? You can get a decent interface for cheap, without having to go through that nonsense!
 
Re: Dual Channel FFT

Mark, even with matched pairs of channels, you still need clock synchronization between input and output, and between multiple interfaces, for your dual channel measurements to be valid. Read that sentence carefully again and again and again until it sticks in your brain. Put together any digital audio system using multiple devices, and you MUST have a word clock master and a bunch of word clock slaves in order for things to cooperate with each other in the digital audio realm. With dual channel measurements it's no different. At present, using only one computer audio interface is a constraint due to differing word clocks between multiple interfaces that are typically designed for a project studio where only one interface is used at any time. If you use multiple interfaces, one needs to be set as the master clock, the rest of them slaved to the master clock, a feature that is not available on most common computer audio interfaces. Yeah, maybe you can mess around with aggregate device managers, or there are exceptions... The new Smaart I/O box has an external clock bus that allows multiple interface boxes to be synchronized, same with the Systune Aubion interface box, and maybe the high end RME stuff and the Roland Octacapture, but everything else is a crap shoot for synchronization.

Not to get completely off my topic and into synchronization issues. I went looking for any papers published on this and I can't find any. There are a lot of publications on clock jitter effects, long haul digital audio, broadcast audio video sync, etc.. Does anyone know of a study on input-output clock synchronization effects on noise measurements? I would be really interested to know, if you take the computer OS timing issues out of the equation, what the effect on the measurements would be.

AES E-Library » Time Delay Spectrometry Processing Using Standard Hardware Platforms

Pretty recent and talks a little bit about all the issues I would imagine to be a problem. But doesn't have any actual data to show how much effect the problems have.

You are also making a lot of ASSumptions on what goes on behind the scenes, the majority of the delay with an internal loopback signal is due to the ASIO or CoreAudio drivers and how the computer audio interface interacts with those drivers, not Smaart itself. I'm not a programmer, nor did I stay at a Holiday Inn Express last night, but you can probably glean some insight in this thread, maybe converse with an experienced programmer like Adam about this:
new to both USBPre2 and SMAART7

Not really sure how SMAART works. In my "theoretical" system it works like this:

Microphone->Cable->ADC->Buffer->Low level DMA->ASIO Wrapper->Main Memory.
While the reference is already in Main Memory.

No extra moves required. Pretty sure this is how EASERA works in single channel mode.

With regards to calibration curves, how would you go about making these without a reference to refer to? In this situation, kinda the chicken before the egg scenario. Why make things more complicated than they need to be? You can get a decent interface for cheap, without having to go through that nonsense!

I'm confused. Whether you use a loop-back cable or not if you want to reference your system to something real it should be calibrated. If you're making relative measurements calibration curves from the output to the input are sufficient?
 
Re: Dual Channel FFT

Not to get completely off my topic and into synchronization issues. I went looking for any papers published on this and I can't find any. There are a lot of publications on clock jitter effects, long haul digital audio, broadcast audio video sync, etc.. Does anyone know of a study on input-output clock synchronization effects on noise measurements? I would be really interested to know, if you take the computer OS timing issues out of the equation, what the effect on the measurements would be.

AES E-Library » Time Delay Spectrometry Processing Using Standard Hardware Platforms

Pretty recent and talks a little bit about all the issues I would imagine to be a problem. But doesn't have any actual data to show how much effect the problems have.



Not really sure how SMAART works. In my "theoretical" system it works like this:

Microphone->Cable->ADC->Buffer->Low level DMA->ASIO Wrapper->Main Memory.
While the reference is already in Main Memory.

No extra moves required. Pretty sure this is how EASERA works in single channel mode.



I'm confused. Whether you use a loop-back cable or not if you want to reference your system to something real it should be calibrated. If you're making relative measurements calibration curves from the output to the input are sufficient?

I think you are missing your own statements. If you are measuring from output to input, then you are making a TWO channel measurement. The input and the output. If all you measure is the output, then there is no way to easily know what the difference between them is.

The loopback provides that reference.
 
Re: Dual Channel FFT

I think you are missing your own statements. If you are measuring from output to input, then you are making a TWO channel measurement. The input and the output. If all you measure is the output, then there is no way to easily know what the difference between them is.

The loopback provides that reference.

Mark DeArman said:
Why don't I just measure the the transfer function from the actual output I'm using direct to the input I'm actually using? Then use that to correct for any timing, AA filtering, other problems. I already have the data for the pink noise being generated inside the computer.

Above was my original question. Assuming there are no timing issues for the moment lets say I measure OUT->AMP->IN1 and OUT->AMP->IN2. I now store these curves and use them as the reference.

Ivan perhaps you could elaborate a little more on your reply because I am confused about what I am missing.
 
Re: Dual Channel FFT

Mark DeArman said:


Above was my original question. Assuming there are no timing issues for the moment lets say I measure OUT->AMP->IN1 and OUT->AMP->IN2. I now store these curves and use them as the reference.

Ivan perhaps you could elaborate a little more on your reply because I am confused about what I am missing.

Hi Mark,

Perhaps Im missing something, but my understanding is as follows:

A single channel FFT does not in general measure a transfer function.

However, a single channel FFT using a pink noise source as the reference will more or less enable you to measure/calculate the transfer function.

A dual channel FFT will work with music but performs better with pink noise. As I mentioned above you can do this as you mix. This can assist you to know where to make your EQ corrections - on the system EQ or the channel strip.

The input and output samples of a dual channel FFT must be accurately time aligned (the time delay in Smaart). It requires many samples to be averaged. The resulting transfer function will exclude most of the random and reverberant noise in the measurement environment; this is the advantage over a single channel FFT or RTA measurement using pink noise.

I’m not sure if what you are proposing is a dual channel FFT where one channel comes internally from the computer or if you are proposing to use a single channel FFT where you correct for the shape of the original signal (?).
 
Last edited:
Re: Dual Channel FFT

Perhaps I missing something, but my understanding is as follows:

A single channel FFT does not in general measure a transfer function.

Yes I would totally agree with that.

However, a single channel FFT using a pink noise source (flat frequency response) as the reference will more or less measure the transfer function.

Off topic, but pink noise doesn't have a flat spectrum. Normally an RTA has an internal reference filter for pink noise that makes the spectrum flat after filtering it.

I’m not sure if what you is proposing is a dual channel FFT where one channel comes internally from the computer or if you are proposing to use a single channel FFT where you correct for the shape of the original signal (?).

Yes I think a lot of terminology is the communication issue on my part. The hypothetical system I'm talking about has an "internal" (in memory) loop back, reference, calibration curve, what ever you want to call it. Like I said, I am pretty sure this is the way it is implemented in EASERA, Sound Check, CLIO and a number of others. My question was whether there were advantages/disadvantages of the dual-channel (burn a hardware input) method over the latter.

I have gleaned a few from this discussion so far:
1) Differential measurements, Point A to Point B.
2) Music source or any source external to the measurement system.
3) Timing Issues in Windows or other OS.
4) Possibly poor COTS DAQ/soundcard hardware designs. I would still like to see some hard data on this one for a typical setup two channel (single stereo ADC) setup.

Thanks,
Mark DeArman
 
Last edited:
Re: Dual Channel FFT

Yes I would totally agree with that.



Off topic, but pink noise doesn't have a flat spectrum. Normally an RTA has an internal reference filter for pink noise that makes the spectrum flat after filtering it.



Yes I think a lot of terminology is the communication issue on my part. The hypothetical system I'm talking about has an "internal" (in memory) loop back, reference, calibration curve, what ever you want to call it. Like I said, I am pretty sure this is the way it is implemented in EASERA, Sound Check, CLIO and a number of others. My question was whether there were advantages/disadvantages of the dual-channel (burn a hardware input) method over the latter.

I have gleaned a few from this discussion so far:
1) Differential measurements, Point A to Point B.
2) Music source or any source external to the measurement system.
3) Timing Issues in Windows or other OS.
4) Possibly poor COTS DAQ/soundcard hardware designs. I would still like to see some hard data on this one for a typical setup two channel (single stereo ADC) setup.

Thanks,
Mark DeArman

Other than the music source, I don’t think there is much advantage in practice of a loop back compared to your suggestion. In any case a dual channel FFT taken in a venue is an ordinary measurement compared to what else can be achieved if you are doing critical testing of speakers, so why sweat some small imperfections … and ooops brain fart :blush: what was I thinking ... thanks!... anyway you still understood where I was coming from :)~:)~:smile:.

Peter
 
Last edited:
Re: Dual Channel FFT

Wow. There is a lot of ground covered in this thread. I won't comment on all of it but there were a few points I wanted to address for clarity.

Firstly there seems to be some confusion on the difference between a single channel and dual channel measurement. They are completely different measurements and serve vastly different purposes. Learning the difference between them and what their applications are is time well spent. I don't mean that in a snarky manner. It's just that understanding the fundamentals of ones toolkit will go a long way to improving their use and thus the results.

In a nutshell the difference is thus. A single channel measurement shows you the spectral content of one signal. In other words, it depicts the amount of energy present for various frequencies. A dual channel measurement shows you the difference between two signals, in frequency, energy and time. In other words, what is in one signal but not the other and by how much. With that distinction made I'll address at the original question.

When you are using a dual channel FFT analyzer, SMAART, EASERA, etc... What does the loop-back channel do to improve the measurement over just a single channel measurement?

The answer is, nothing. Using a dual channel measurement doesn't improve anything in relation to a single channel measurement. They aren't like quantities.



Why don't I just measure the the transfer function from the actual output I'm using direct to the input I'm actually using? Then use that to correct for any timing, AA filtering, other problems.

Assuming that you're using the output as your reference signal and the input as your measurement signal, this is perfectly acceptable for a dual channel measurement. Getting the output signal via a hardware or software loop back is merely a convenience and requires less cabling. Though as Langston pointed out, the hardware path is nice in that the reference signal underwent the same D/A and A/D processing as the measurement signal. Whereas with the software path the reference signal remained in the digital. Which is precisely why the software loop back has additional delay. More on this below.


Strange, the extra propagation delay must be a behavior inherent to Smaart. In fact there should be more usable bandwidth available as the reference is already stored in memory. I don't see how a system designed to work as I described would suffer from extra propagation delay or clock synchronization issues after calibration measurements had been made.

The added delay isn't propagation delay, but rather the lack of propagation delay for the reference signal. With a software loop back, the reference signal has virtually no propagation. It's created in the digital and remains in the digital before being fed to the measurement. Whereas, at a minimum, the measurement signal undergoes a D/A and A/D conversion and some amount of additional processing and propagation before it reaches the measurement. This process takes a finite amount of time, considerably more time than it took the reference signal. As we are measuring the difference between the two signals, the difference is manifested as additional delay.

Hopefully that clears things up for you.

-A
 
Last edited:
Re: Dual Channel FFT

The added delay isn't propagation delay, but rather the lack of propagation delay for the reference signal. With a software loop back, the reference signal has virtually no propagation.

Thanks Adam,
I didn't really believe SMAART would have had a 50ms delay for keeping the stimulus in memory, that just didn't make any sense to me.

Do you have any comments or additions to my list of applications for the actual dual channel measurement over the in-memory based system?

Mark DeArman
 
Re: Dual Channel FFT

Do you have any comments or additions to my list of applications for the actual dual channel measurement over the in-memory based system?

Not sure I understand the question. I'm reading it as asking if there are advantages to a physically loop backed reference signal versus a software loop backed reference signal. From a measurement perspective, no not really. In fact the additional delay of the software based solution could be problematic if using the measurement for timing purposes. The single biggest advantage to the software solution is the gained input. If you're using a two channel device and one input is being used to patch the output signal to an input, you are left with a single input for a mic. Thus you can only do one dual channel measurement at a time. Whereas with a software loop back you can use both inputs for mics and do two dual channel measurements at the same time. Given the cost of multi channel pre amps, this is a good way to move in to the multi measurement realm without having to invest in another device.

-A
 
Re: Dual Channel FFT

Thanks Adam,
Do you have any comments or additions to my list of applications for the actual dual channel measurement over the in-memory based system?

Mark DeArman
The advantage would be if you were using some source other than the programs generator to measure the difference.

For example during a live performance-you could use the output of the console as the reference and the mic as the measurement.

Of course the accuracy of this would depend greatly on the level of the PA vs the level of the sound that is heard. That is PA + stage volume, which would be instruments amps and monitors.

If there is a large difference-then the stage volume would not affect the measurement. If not so big a difference-then that type of measurement would be pretty much meaningless.
 
Re: Dual Channel FFT

One other reason to run the stimulus out to the real world is that you may want to measure the transfer function of a part of the audio system and exclude the computer and it's interfaces. For example, if I want a transfer function of the "amp rack" which may include a DSP or crossover or such, then I want to take my reference on the input to the amp rack, and the measurement on the output of the amp rack. Most often I am measuring the "system" which includes the speakers. So, I again want my reference to be after the mixing board so it isn't including things like channel eq or output eq and the measurement is from a mic.

If the reference is kept local to the computer then the transfer function includes the I/O of the computer and any thing else in the audio path. Not useful for me at least.
 
Re: Dual Channel FFT

My question was whether there were advantages/disadvantages of the dual-channel (burn a hardware input) method over the latter ("internal" (in memory) loop back, reference, calibration curve, what ever you want to call it.)

I have gleaned a few from this discussion so far:
1) Differential measurements, Point A to Point B.
2) Music source or any source external to the measurement system.
3) Timing Issues in Windows or other OS. (Of the random variety.)
4) Possibly poor COTS DAQ/soundcard hardware designs. I would still like to see some hard data on this one for a typical setup two channel (single stereo ADC) setup. (Of the random variety.)

I figured I'd move my list to the bottom of the thread since people are having a hard time finding it.
 
Last edited: