Impulse and decay different between back to back measurements

torarnv

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
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.


1684178039328.png

1684177880803.png


1684177789085.png


Why could this happen?

The frequency response seems to at least be the same:

1684177954086.png


Attached is 3 measurements back to back. Any ideas?
 

Attachments

  • Test fluctuations.mdat
    5.5 MB · Views: 2
  • 1684177859322.png
    1684177859322.png
    82.6 KB · Views: 5
Last edited:

John Mulcahy

REW Author
Joined
Apr 3, 2017
Messages
7,212
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

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
Aaah, I naively set it to 1M based on some guide that said higher is better :greengrin:

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

torarnv

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
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:
1684182420099.png

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

torarnv

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
Including my UMIK-1 in the aggregate device, so that they would all share the same clock:

1684182818007.png

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

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

In any case, still getting this:

1684182996356.png
 

torarnv

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
Should I be using the non-beta version of REW for this in case something changed in the development version?
 

John Mulcahy

REW Author
Joined
Apr 3, 2017
Messages
7,212
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

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
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:
1684255411193.png

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

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
What happens is that the two first measurements are okey, then after the third one, REW looks like this:

1684257260706.png

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

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

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
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

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
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:
1684259014871.png
 

torarnv

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
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

REW Author
Joined
Apr 3, 2017
Messages
7,212
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

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
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

REW Author
Joined
Apr 3, 2017
Messages
7,212
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

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
Buffer size 32, 10 repeated measurements, at end of number 4, this popups up:
1684261305457.png


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?
 

Attachments

  • 32k, 10 measures, failed after fourth.mdat
    5.7 MB · Views: 2
  • 512k buffer, all 10 measures completed.mdat
    14.3 MB · Views: 3

torarnv

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
Here's a video showing what's happening:


 

John Mulcahy

REW Author
Joined
Apr 3, 2017
Messages
7,212
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.

1684262606242.png
 

torarnv

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
Thanks for your help John!! I've experimented with various combinations of inputs and outputs the past days, resulting in

Output / InputUMIK-1MOTU Audio Express Mic iniMac Pro Microphone
MOTU Audio ExpressClock adjustments ranging from -26 to -190, eventually resulting in "clock adjustment unusually high" at -450Does 1-2 successful measures, then stops receiving input, the input graph is paused, and eventually leads to
1684493697925.png
All captures successful, with a clock adjustment of -20 to -30 ppm, often -21.8.
iMac Pro Speakers"clock adjustment unusually high" at ~1500All 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 :sad:
 

torarnv

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
Tried locking the clock of the MOTU to the UMIK, no change:

1684495523566.png
 

torarnv

Registered
Thread Starter
Joined
May 15, 2023
Messages
19
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!
 
Top Bottom