Impulse and decay different between back to back measurements

[torarnv]

Hi all!

I just started experimenting with REW, using my UMIK-1 microphone, but I've noticed something that confuses me. If I do back to back measurements, with the same microphone position, speaker, volume, etc, I'm seeing very different impulse responses and decay times.

Why could this happen?

The frequency response seems to at least be the same:

Attached is 3 measurements back to back. Any ideas?

 

[John Mulcahy]

You are using a very long sweep, 1M. With a USB mic there will usually be a difference between the clock rate of the microphone (derived from the USB clock) and the clock rate of the output device. That clock rate difference will affect the impulse response shape, but not the magnitude response. It can be helped by using shorter sweeps (256k is plenty for acoustic measurements) and enabling the acoustic timing reference and the Analysis preference to Adjust clock with acoustic ref, which lets REW use the timing reference positions to correct the clock rate.

 

[torarnv]

Aaah, I naively set it to 1M based on some guide that said higher is better

I'll reduce the sweep and play around with the timing reference, thanks!

 

[torarnv]

I tried playing the reference sound via my iMac Pro's built in speaker (creating an aggregate device in macOS of my built in speakers and my MOTU AudioExpress), and sometimes it seems to work, but other times I get:

Is it okey to play the reference sound from the right speaker while measuring the left speaker?

 

[torarnv]

Including my UMIK-1 in the aggregate device, so that they would all share the same clock:

But attaching the cal file to the new aggregate input in REW seems to not work fully:

Don't know if that matters if I calibrate the SPL?

In any case, still getting this:

 

[torarnv]

Should I be using the non-beta version of REW for this in case something changed in the development version?

 

[John Mulcahy]

Is it okey to play the reference sound from the right speaker while measuring the left speaker

Yes

Including my UMIK-1 in the aggregate device, so that they would all share the same clock

There are limits to how reliably separate devices can be made sample synchronous by the OS and from the messages it appears to be making things worse. REW will also no longer recognise the input as coming from a UMIK if the input name no longer contains UMIK-1. I don't recommend aggregate devices.

 

[torarnv]

Ah, so the important thing about the reference sound is that it's from a stable speaker position, so that you can then e.g. move the tested speaker around the room? If so, I could in theory use the same speaker for the reference signal as I use for the test sweep, as the speaker is always in the same spot and I'm just measuring the room?

I've now switched away from the aggregate device, only using my MOTU for the output and UMIK for the input:

But I'm still seeing the "clock adjustment unusually high" message. I guess that means the UMIK and MOTU are drifting too much apart?

I've chosen "Mode: repeated measurements", which as I understand it is different from the "Repetitions" setting at the top of the dialog. The latter should not be used when input and output is on a different device, but the former is presumably just a convenient way of not having to press "Start" 3 times? I can hear the reference tone being played before and after each repeated test at least, so they should be independent.

 

[torarnv]

What happens is that the two first measurements are okey, then after the third one, REW looks like this:

Dismissing the modal dialog I'm left with all 3 measurments, but I don't know if they are correct or not:

It seems to also put REW in a weird state when this happens sometimes, where I close the measure dialog, and suddenly it starts a final measurement, playing sound through the speakers but without any measuring UI visible. The sweep "task" is probably still queued?

 

[torarnv]

I tried doing single measurements now, and two of those 3 worked, but the last one gave the same "clock adjustment unusually high" message, so it doesn't seem to be related to the multiple-measure-feature.

 

[torarnv]

Tried increasing the buffer size on both UMIK and MOTU to 512. I now get a few more measurements in (tried 10, got 5), before seeing:

 

[torarnv]

Another attempt of 10 successive measurements finally worked, buffer size 512. I guess I was lucky this time The clock adjustment of these are around -26ppm for a handful, and -170 to -190ppm for the rest.

 

[John Mulcahy]

Buffer size 512k in REW? That's really extreme, I normally use 16k. Could you post an mdat with a few of the measurements?

 

[torarnv]

Buffer size 512k in REW? That's really extreme, I normally use 16k. Could you post an mdat with a few of the measurements?

Yeah, 32k was the default, was just trying if 512k did somehow fix the audio reference issue above. Do you want mdat with the ones from 512k? Or the ones that are saved once the "clock adjustment unusually high" error happens?

 

[John Mulcahy]

Some of both would be interesting. At the end of each measurement REW shows the captured sweep data on the Captured graph. If you make individual measurements and get a strange one it is worth looking at that graph to see if something odd has happened, such as the capture being truncated. The data is only for the last measurement made.

 

[torarnv]

Buffer size 32, 10 repeated measurements, at end of number 4, this popups up:

Both the start and end acoustic reference was played, and seem to show on the input graph.

Also did 10 repeated measures at 512k, which succeeded. Attached.

One thing I notice while the measures are being done is that in the input graph, the noise floor seems to vary quite a bit. Sometimes it's all in the blue, and sometimes it's up in the greens. I've calibrated my output to 80dB(c), which should be plenty of headroom as far as I understand?

 

[torarnv]

Here's a video showing what's happening:

 

[John Mulcahy]

There's plenty of headroom. -26 ppm looks correct for your setup, when you see other delay figures it looks to be caused by dropouts in the data. If you look on the distortion graph for the measurements with high clock corrections you may notice odd bumps in the distortion, like this one at about 360 Hz. Those are likely caused by missing data. Given the buffer sizes on the REW side there would need to be some fairly dramatic demand on resources to starve the capture thread long enough to cause a dropout, or the dropout could be happening elsewhere. If you have any other mic around it may be worth trying a few measurements with that, just to see how they turn out and whether similar issues arise.

 

[torarnv]

Thanks for your help John!! I've experimented with various combinations of inputs and outputs the past days, resulting in

Output / Input	UMIK-1	MOTU Audio Express Mic in	iMac Pro Microphone
MOTU Audio Express	Clock adjustments ranging from -26 to -190, eventually resulting in "clock adjustment unusually high" at -450	Does 1-2 successful measures, then stops receiving input, the input graph is paused, and eventually leads to	All captures successful, with a clock adjustment of -20 to -30 ppm, often -21.8.
iMac Pro Speakers	"clock adjustment unusually high" at ~1500	All captures successful, with a clock adjustment of 15 to 22 ppm, often 21.8.	"clock adjustment too large" at -600ppm after a few measures. Also often hangs at "waiting for timing reference", but not playing any reference signal

(Timing always R, sweep always L. Always 48kHz. Attempted 10 repeated measurements)

Tried connecting UMIK-1 via USB-C to iMac Pro rather than USB-A. No change.

Will continue to investigate

 

[torarnv]

Tried locking the clock of the MOTU to the UMIK, no change:

 

[torarnv]

Some good news at last (sort of)! I booted my iMac Pro into Windows via Bootcamp, and there UMIK-1 + MOTU works as expected, producing around -26ppm for every single measurement.

I guess I'm doing my measurements in Windows then

I have no idea why things don't work as they should on the macOS side. Happy to debug this further John if you want, e.g. via a debug build or one with more logging of the audio thread. Just let me know!