REW Questions

[Krunok]

Even for panels? I know a .5m panel measurement will give innaccurate FR--is phase immune to that issue? And .5m seems like it would create issues in many box speakers too, at least at crossover points.

I never measured panel speakers but I haven't noticed any issues with my floorstanders even at 15cm. In my experience when doing correction mannually the best results I got was when measuring LF at LP with RTA pink noise (moving mic method, at least 1m2 area and at least 60 samples). With near field I was measuring phase response.

In ideal situation you would be fixing phase (timing) of the drivers and passive XO based on measurements in the anechoic environment. As you can't do that at home near field phase measurement is next best choice.

 

[Daverz]

OK, I did the simple test I should have done a long time ago: 4M sweep with a loopback, using a Behringer U202 for playing the sweep from REW and looping the Behringer's analog output to its analog input. And you get the expected spike:

Then a sweep played back from the music server, taking the output from the analog out of my Auralic Vega and feeding it to the analog input of the Behringer:

So that is what happens when you are using different clocks for playback and recording.

 

[JohnPM]

@RayDunzl's impulse response measurements for various sweep lengths look quite different. Obviously, they can't all be correct at the same time. Most likely, all of them are wrong. It is worrying that REW would display incorrect impulse responses without warning the user that something might be off. Should REW attempt to detect clock drift and warn the user if it happens? Or better yet, should REW attempt to compensate for clock drift automatically (e.g. by resampling)?

The issue looks to me like clock rate offsets rather than drift, i.e. the clocks are stable but slightly different. I'm not sure how REW could detect that, what would the reference be? Happy to hear suggestions though, perhaps @pkane could comment as the master of timing comparisons . When the issue first came up on the AV Nirvana thread I made a test build with manual resampling of the captured sweep to shift the clock rate and could restore normal impulse responses with trial and error adjustment of the rate.

 

[pkane]

The issue looks to me like clock rate offsets rather than drift, i.e. the clocks are stable but slightly different. I'm not sure how REW could detect that, what would the reference be? Happy to hear suggestions though, perhaps @pkane could comment as the master of timing comparisons . When the issue first came up on the AV Nirvana thread I made a test build with manual resampling of the captured sweep to shift the clock rate and could restore normal impulse responses with trial and error adjustment of the rate.

A linearly increasing/decreasing phase slope indicates a simple group delay (constant time offset). This doesn't require resampling to fix, just a simple delay.

A non-linear phase relationship can be due to mismatched clock speeds or variable group delays, among other things.

 

[JohnPM]

It isn't linear though. On a loopback measurement a rate mismatch will show up as a constant slope on a log frequency scale graph, so it's fairly easy to spot there, but room measurements tend to have pretty funky group delay plots and are rather less amenable to extracting the rate error.

Edit: Added group delay plot of loopback measurements with some clock offsets to illustrate, aligned them to approximately zero at 1 kHz for convenience.

 

[JohnPM]

I'll add a feature in V5.21 to have a second timing reference after the sweep and compensate for clock mismatch automatically using that, but it is too big a change to go in 5.20. In the meantime I have added a manual rate adjustment feature for the next V5.20 beta build.

 

[pkane]

It isn't linear though. On a loopback measurement a rate mismatch will show up as a constant slope on a log frequency scale graph, so it's fairly easy to spot there, but room measurements tend to have pretty funky group delay plots and are rather less amenable to extracting the rate error.

Edit: Added group delay plot of loopback measurements with some clock offsets to illustrate, aligned them to approximately zero at 1 kHz for convenience.

View attachment 28738

Here's what a clock speed difference looks like on a linear-scale phase graph. The two tracks were captured with the same ADC but different DACs:

 

[Daverz]

I'll add a feature in V5.21 to have a second timing reference after the sweep and compensate for clock mismatch automatically using that, but it is too big a change to go in 5.20. In the meantime I have added a manual rate adjustment feature for the next V5.20 beta build.

Great!

I wrote a little script that does this for me, and it seems to work. I made my own measurement file with timing chirps before and after the sweep. Then I locate the chirps in the recording by cross-correlation to find the separation between the timing chirps, resample by the FFT zero-padding method to match the original separation, and then compute the impulse response. The impulse might be more symmetric with a bit of tweeking (I didn't try interpolating).

For a Topping D10 as output and a Behringer U202 as input, the Behringer is 1.00011 times faster, which is about 470 samples or about 10 milliseconds shorter over the sweep time.

 

[pkane]

I'll add a feature in V5.21 to have a second timing reference after the sweep and compensate for clock mismatch automatically using that, but it is too big a change to go in 5.20. In the meantime I have added a manual rate adjustment feature for the next V5.20 beta build.

That'll be an excellent improvement!

Unrelated to this, is there a way to make the timing reference a bit more robust, so that some noise in an interface wouldn't trigger the beginning of a sweep? I had this problem a while back with an interface that was generating noise. The sweep was triggered by noise instead of the actual acoustic reference. Maybe if the timing reference could contain a few different frequency chirps, in sequence?

 

[Daverz]

I was able to do an actual recording of my speakers (using Audacity) with the dual chirp measurement file.

It turns out the clock in the UMIK-1 ADC runs 0.99995 times slower than the Auralic Vega DAC, which results in a 4 millisecond longer recorded sweep, and is enough to create the messy impulse response above. I was always perplexed that my phase coherent and time aligned Vandersteens exhibited such a poor impulse response.

Here it is with the recorded sweep resampled:

That's without any room correction.

Thanks to JohnPM for suggesting a solution to the differing input/output clocks problem.

 

[dc655321]

I was able to do an actual recording of my speakers (using Audacity) with the dual chirp measurement file.

View attachment 28786
It turns out the clock in the UMIK-1 ADC runs 0.99995 times slower than the Auralic Vega DAC, which results in a 4 millisecond longer recorded sweep, and is enough to create the messy impulse response above. I was always perplexed that my phase coherent and time aligned Vandersteens exhibited such a poor impulse response.

Here it is with the recorded sweep resampled:

View attachment 28788

That's without any room correction.

Thanks to JohnPM for suggesting a solution to the differing input/output clocks problem.

That's some nice sleuthing!
Would you care to post your script somewhere (or PM me)?
I'm curious and would like to learn from your solution.

 

[Daverz]

That's some nice sleuthing!
Would you care to post your script somewhere (or PM me)?
I'm curious and would like to learn from your solution.

It's a python script. I'll post a link after I've cleaned it up a bit.

 

[Daverz]

It's a python script. I'll post a link after I've cleaned it up a bit.

The script and the needed measurement sweep files with the chirps at either end are here:

https://www.dropbox.com/sh/48e9f5vfw73clhd/AAA0igOBwZVngDD-zNVw7XvGa?dl=0

TL;DR

Play the wav files and save your recordings as 32-bit floating point wav files and run, e.g.

python resample_sweep.py sweep_L.wav impulse_L.wav

to produce the "corrected" impulse response file from the recorded sweep.

I recommend installing the Anaconda Python 3 distribution, which has everything needed to run the script.

Currently the script only supports 48000 samples/sec (the supported UMIK-1 rate) and the sweep parameters are all hardcoded. It would be nice to have command-line switches to support creating new sweep files with different parameters. Maybe. It sounds like John will add the ability to adjust the impulse response by hand in the next release of REW.

How does it work?

The bookending timing chirps in the recording are found by cross-correlation and the separation between them is found. This is compared to the separation in the original file and their ratio is turned into a fraction (numerator/denominator). These are used for the upsample and downsample factors for polyphase resampling of the recorded sweep to correct for the clock rate differences. The impulse response is then produced in the usual way from the corrected sweep.

 

[dc655321]

The bookending timing chirps in the recording are found by cross-correlation and the separation between them is found. This is compared to the separation in the original file and their ratio is turned into a fraction (numerator/denominator). These are used for the upsample and downsample factors for polyphase resampling of the recorded sweep to correct for the clock rate differences. The impulse response is then produced in the usual way from the corrected sweep.

That is what I suspected you must be doing. Nice to see it reified though.
Thanks for making that available for inspection.

 

[Daverz]

The issue looks to me like clock rate offsets rather than drift, i.e. the clocks are stable but slightly different. I'm not sure how REW could detect that, what would the reference be? Happy to hear suggestions though, perhaps @pkane could comment as the master of timing comparisons . When the issue first came up on the AV Nirvana thread I made a test build with manual resampling of the captured sweep to shift the clock rate and could restore normal impulse responses with trial and error adjustment of the rate.

A kind ASR member sent me a link to this paper on impulse response measurement

https://www.researchgate.net/public..._impulse_response_measurements_by_sine_sweeps

that suggests two other ways of correcting the clock mismatch:

* Similar to the above method, but instead of adjusting the measured sweep, re-generate the original sweep and the resulting inverse sweep to match the measured sweep. May be less CPU-intensive than resampling.

* Making a reference measurement (e.g. from the DAC or pre-amp) and using that with the Kirkeby algorithm to "straighten" out the measurement. I assume you need to use the same clock for recording of the reference and playback of the excitation signal. His description of the Kirkeby algorithm is brief, but I do see several other hits on Google for it.

 

[JohnPM]

I decided to bite the bullet and implement automatic correction for the next build. I've already done the acoustic timing reference correction, today I'll add automatic correction for a loopback timing reference. I have a different approach for that (already used for the manual correction feature) which looks to work well.

 

[Daverz]

* Making a reference measurement (e.g. from the DAC or pre-amp) and using that with the Kirkeby algorithm to "straighten" out the measurement. I assume you need to use the same clock for recording of the reference and playback of the excitation signal. His description of the Kirkeby algorithm is brief, but I do see several other hits on Google for it.

Thinking about it a bit more, you can't use this Kirkeby method to fix recordings with the UMIK because any reference will be recorded with another clock. But you can use it to fix playback from a standalone DAC if you record the reference and the output of an analog mic with the same soundcard.

More info on the Kirkeby algorithm here:

http://www.bodziosoftware.com.au/Comments_On_Kirkeby_Method.pdf

 

[Daverz]

I decided to bite the bullet and implement automatic correction for the next build. I've already done the acoustic timing reference correction, today I'll add automatic correction for a loopback timing reference. I have a different approach for that (already used for the manual correction feature) which looks to work well.

I haven't been this excited about the next point release of a piece of software since my Slackware days.

 

[Earfonia]

I hope this thread for all general question related to REW. My question is not related to Impulse Response, but maximum SPL from calibration.

Basically I was trying to calibrate 3 difference PCs, 2 laptops and 1 desktop, all installed with REW V5.20 Beta 29.
The audio interface is RME Babyface Pro, I use the Output 3-4 3.5mm headphone output and the Input 1, XLR input.

Setup:
RME Babyface Pro Out 3-4 ---> Earphone (Yinyoo V2) ---> IEC60318-4 Compliant Coupler ---> Rode VXLR+ ---> RME Babyface Pro Input 1 XLR

The IEC60318-4 Compliant Coupler has build-in condenser microphone that required plug-in power. The Rode VXLR+ converts the 48V phantom power to around 4V-5V plug-in power voltage for the condenser mic in the coupler:


The same setup above, I connected to 3 different PC as mentioned earlier. All use the same calibration file for the XLR input that is connected to the IEC60318-4 Compliant Coupler. I didn't change the setup at all, so the earphone was plugged into the coupler without changes.

The RME Babyface Pro Input gain and Output level were set the same on all 3 PCs.

What I don't understand is the 'Maximum SPL with this calibration' showing different result on the 3 different PCs, as shown below:

Laptop1:

Laptop2:

Desktop PC:

May I know what have I done wrong? Why different Max SPL on the 3 different PCs for the same setup with the same audio interface?

Thank you!

 

[JohnPM]

Most likely is that the Windows volume controls for input and/or output are set differently. Should also check that the View preference "Full scale sine rms is 0 dBFS" is set the same for all installations. Probably better using ASIO drivers to remove Windows audio settings as a source of differences.