# strange soundcard calibration graphs



## user42 (May 14, 2014)

I have my soundcard's output looped back into its input, and I ran a calibration. The results are very strange.

Here's the 'SPL and Phase' graph:








And here's part of the 'Scope' graph:








Can anyone make any sense of this?

It looks like the output and the left and right inputs are all running at different sample rates somehow. I have no idea how that could possibly happen, though.

edited to add: But the distortion graph looks fine. A nice straight horizontal line for the fundamental, with all the harmonics 85 dB or so below it.


----------



## JohnM (Apr 11, 2006)

Worth posting the mdat file to look at. The sweep starts at low frequency and progresses to high, so time delays from output to input usually mean the sweep on the scope is ahead of the captured signals. Not seen the left and right channels have different delays before though, difficult to achieve that without some intervening processing. What soundcard and how is the loopback connection made?


----------



## user42 (May 14, 2014)

Here's the .mdat file.

My computer is an HP h8-1220 running Windows 7 and I'm using the built-in sound, with Windows' High Definition Audio driver.

The soundcard's output and input are hooked up to an input and output of my amplifier (Yamaha A-S500). It has a switch on the front panel that is used to choose which input gets sent to all the outputs. The signal gets attenuated somewhat in passing through the amp. I don't know whether it gets delayed too.

But I don't think the problem is with the physical set-up. If I tell REW to take a regular measurement instead of a soundcard calibration, that works ok, with the same set-up.

The problem is not consistent. Sometimes calibration gives reasonable results, sometimes it gives nonsense, sometimes something in between. The problem seems to be related to switching sample rates, either between 44.1 kHz and 48 kHz within REW or, in Windows' Sound control panel, between different sample rates and bit depths to be used when running in shared mode.


----------



## Kix_N_Grins (Feb 14, 2015)

Hello user42,

I'm somewhat of a new user of REW myself, so don't take my reply as gospel. I'm kind of hoping the board experts will tell me that "I'm getting it" with my response to you.

I believe the purpose of the soundcard calibration is to remove everything in the circuit except for the soundcard itself, which means your amp should not be in the circuit. Once the freq response of your soundcard is measured and known, a signal that is exactly the opposite is applied by REW, which basically makes the overall freq response as flat as a ruler (kind of like equalizing itself), and eliminating it as being a part of the measurement of your hardware (amps, speakers, etc).

The output of your soundcard needs to be directly feeding the input of your soundcard, and you should only be using the right channel. So if your soundcard has 1/8" female stereo connectors for input/output, you're going to need to separate the right and left channels, and disconnect the left. You could modify a 1/8" male to 1/8" male cable by severing the left channel wire somewhere in the cable (making it useless for anything but REW). Or, you can use a cable or adapter that's 1/8" male on one end, and separate right/left RCA connectors on the other end (you'll need two, one for input and one for output). You then would use a RCA cable to connect just the two right RCA connectors together.

Good luck and have fun,

Kix


----------



## jtalden (Mar 12, 2009)

user42,
Your soundcard measurement is normal, but for some reason the IR is delayed at just over 5000ms. If the IR is shifted back to 0ms and window set to normal settings then all looks normal as shown below.









JohnM,
With v5.11 I have recently seen this same issue with some of my measurements. In a recent session the IRs were located at about 6000ms. I just pulled up another earlier session and the IRs were located near 1000ms. A quick look at an even older v5.1 file shows the IRs are near -1000ms so there seems to big difference for some reason.


----------



## JohnM (Apr 11, 2006)

That is a bit odd. My best guess is that it might be caused by Java's garbage collection process, which can stop everything while it frees up memory. That could be more likely to happen if using options that increase memory use, such as having the Analysis Impulse Response Calculations preference set to "Keep full IR" rather than "Truncate IR after 1.7 s" or using long sweeps.

There are some startup options for the VM that may help if that is the cause. In the REW installation directory (usually C:\Program Files (x86)\REW) there is a file called roomeqwizard.vmoptions, open that in a text editor and add this line:

-Xms1024m

(with the minus sign at the start of the line). That tells Java to allocate a minimum heap size of 1GB, which is also the maximum heap size, so the heap never has to grow. Another option that may help is:

-XX:MaxGCPauseMillis=200

That tells the garbage collector that it must not stop Java running for more than 200 milliseconds.

After making a change to the vmoptions file save it (make sure it doesn't end up with an extra file extension appended) then if REW is open close and restart it. Note that you may have to save the file to your documents folder or the desktop and move it back afterwards, as admin privileges are required to make changes in program directories.

If you get a chance to try running REW with either or both of those options (I suggest trying -Xms1024m first) please let me know if it had any effect on the IR peak timing offsets.


----------



## user42 (May 14, 2014)

Kix_N_Grins said:


> I believe the purpose of the soundcard calibration is to remove everything in the circuit except for the soundcard itself, which means your amp should not be in the circuit.


I think you're right about that, but I also think that the amp is not the cause of the strange result I got.


----------



## user42 (May 14, 2014)

I'm looking at REW's Scope graph. The 'sweep' trace starts rising at about 100 ms. The 'ref captured' trace starts rising before 400 ms. So, the difference in start times is less than 300 ms. But now look at when they end. The 'sweep' ends at about 4.5 s. The 'ref captured' keeps going until after 21 s.

The 'ref captured' doesn't seem to be delayed. It seems to be stretched.


----------



## JohnM (Apr 11, 2006)

That would suggest it was being sampled at a much higher rate, but I don't know how that would be possible. The timing reference is not used for soundcard calibration measurements in any case, so could try unticking the Analysis preference to use loopback as timing reference and see if it makes any difference.


----------



## jtalden (Mar 12, 2009)

JohnM said:


> -Xms1024m
> 
> (with the minus sign at the start of the line). That tells Java to allocate a minimum heap size of 1GB, which is also the maximum heap size, so the heap never has to grow. Another option that may help is:
> 
> ...


 Thanks a heap. Although it sounds like garbage to me! 

I will try those options and advise.

Some previous investigation findings in case it is helpful:
> It can happen on a fresh startup without other program demands.
> The fault measurements show the IR to be twice as long. In my case instead of ~6s it is ~12s with the IR peak falling at end of the 1st interval. Maybe it is more likely a the start of the 2nd?
> Changing from ASIO to Java and back was not a reliable way to fix it. 
> Changing from a 256 buffer in AISO to 512 did not reliably fix the issue, but after several changes some of which indicated the driver would be reset, it finally started to work normally within the same session.

Attached is session file that shows some of this. See the measurement notes.

View attachment Misplaced IR -2.mdat


I will try the vmoptions when I get chance.


----------



## jtalden (Mar 12, 2009)

Oops wrong REW file. Now it won't let me attach the correct one to this post. It tells me there is a security token missing.

I'll try again later.


----------



## user42 (May 14, 2014)

JohnM said:


> That would suggest it was being sampled at a much higher rate, but I don't know how that would be possible.


That's what I thought at first too. But then I zoomed into the scope trace, so that I could see the individual samples, and now I think that the timing reference trace shown is actually from a previous regular measurement that was done with 1 M samples, while the current calibration measurement was done at 256 k samples.



JohnM said:


> The timing reference is not used for soundcard calibration measurements in any case, so could try unticking the Analysis preference to use loopback as timing reference and see if it makes any difference.


I can't reproduce the problem now, whether that box is ticked or unticked.

If I run a calibration after a regular measurement, the scope for the calibration does show the timing reference from the preceding regular measurement, but the 'SPL and Phase' graph for the calibration is fine anyway.


----------



## jtalden (Mar 12, 2009)

JohnM said:


> That is a bit odd. My best guess is that it might be caused by Java's garbage collection process, which can stop everything while it frees up memory. That could be more likely to happen if using options that increase memory use, such as having the Analysis Impulse Response Calculations preference set to "Keep full IR" rather than "Truncate IR after 1.7 s" or using long sweeps.


 I did set "Keep Full IR" to see if it help with an IR import from Holm. It did not and I forgot to change back. I think this intermittent issue started about the time of the change so it is suspect. I have now changed back. So far the problem has not reoccurred. For now all is well an I am guessing you were correct that it was the cause. I will monitor it for a while and let you know if the problem comes up again.


----------



## JohnM (Apr 11, 2006)

user42 said:


> If I run a calibration after a regular measurement, the scope for the calibration does show the timing reference from the preceding regular measurement


Yes, noticed that yesterday while trying to reproduce the problem you saw. I've fixed it for the next release.


----------

