# Time delay of direct path in RIR measurement

I am trying to measure an RIR using my laptop and a JBL Flip 5 speaker. I have tried, both, the Matlab tool and a python code shared on gihub. My final goal is to compare with the image method and analyzing some differences. In both cases, I am getting a very late direct path with $$f_s=44100KHz$$. The image of the Matlab tool, shows the first arrival after $$t_1=0.3$$ sec:

The python one after 20000 samples, which translates to $$t_2=\frac{20000}{44100}=0.4535$$:

The speaker is located no more than 3 meters from the laptop. Taking into account, a speed of sound $$C=343_{\frac{m}{sec}}$$, this means that the calculated distances are $$d_1>t_1C=0.3\cdot343=102.9_m$$ and $$d_2>t_2C=0.4535\cdot343=155_m$$. These distances are not even close.

Something does not add up for me. Do I have to take the BT communication time, into account? What am I doing wrong?

• Does this time delay important to you? What excitation signal did you use? Jul 19 at 9:15
• I am trying to compare with the Image method. I know they will yield different results. I want to compare and analyze the differences. I have just added this to the question. Thanks. Jul 19 at 16:46

Do I have to take the BT communication time, into account?

Yes. Plus also the delays in your audio drivers, the audio stack of the OS, kernel mixers, sample rate converters, and whatever else is in the signal chain.

Your best shot is to try a calibration: Do a near field measurement at close range (maybe 5 cm in front of the center of the full range driver, not the passives on the side). Eyeball the delay and subtract 0.14ms for your 5cm measuring distance. That's your baseline delay.

Repeat this a few times and see if it's stable or if it drifts. Repeat again but unpair and repair the speaker. Then repeat again a few times but reboot everything between trials.

If all of the repeats give you the same baseline delay, you can calibrate your setup simply be shifting your measured impulse responses.

If your baseline delay is not constant, your setup is not really suitable for measuring absolute delays. As a workaround you can measure your baseline delay before and after the real measurement. If you get the same answer, you can be 95%+ sure that the same delay is in your real measurement.

• The "Eyeball the delay" part will most definitely cause this process to be unstable. The question is, what is considered unstable? I have repeated this 3 times and got a delay of 23628, 22963, and 22620 samples, for the maximal peak. Is that considered to be relatively constant? Is that a delay of 22000 samples? Jul 20 at 6:15
• No, this is not considered relatively constant. It just means that your audio latency is drifting around a lot which is unfortunately pretty normal for especially for Windows. Bluetooth also has a non-constant latency. Jul 20 at 11:44