HOLMImpulse: Measuring Frequency & Impulse Response

Reverberation button

Reverberation button:

1. Shows the Impulse Response in dB
2. Zooms out so that the reverberation can be seen

(Does not change the measurement only the prensentation)
 

Attachments

  • new picture (1).png
    new picture (1).png
    43.9 KB · Views: 835
Ask

Also, please don't loose my request to see the actual source and receive time signals as this is very valuable information when debugging a setup (you never mentioned this).

I had trouble with level issues as one other poster commented, but it took a while to track this down. If I could have seen the signals being used then I would have known immediately what the problem was. I simply do not trust any measurement where I can't see the raw data being used.

The program does look like a very good start - it could be great.
 
No ASIO support yet.. + Levels

Now HOLMImpulse does not have ASIO support - only MME

The audio library (PortAudio) can support ASIO, but I see no need for that yet. (The increased latency in MME is no problem for such an application)

ASIO
- Do you have soundcards, that have ASIO, but not MME?
- How much do you prioritize ASIO support?

Levels
The logsweep send via MME has full level and HOLMImpulse does not do anything for the MME volume settings. In XP the master and wave volume must be adjusted. In Vista the application level and recording level.

Audacity
Audacity also uses PortAudio with MME-support.
In Audacity you can see the out->in waveforms, so until HOLMImpulse shows the out->in waveform, you can use this application for troubleshooting the MME sound-levels.
(In audacity you can generate waveforms)
 
Showing the Waveforms is not a simple task

gedlee said:
Also, please don't loose my request to see the actual source and receive time signals as this is very valuable information when debugging a setup (you never mentioned this).
Maybe you are right, but showing the Waveforms is not a simple task :bawling:
  • How to integrate in GUI
  • Performance, Performance, don't slow measuring down
  • Performance, zooming, latency, ...
I have to think... :scratch: :scratch2:
Thanks for the feedback :up:
Don't misunderstand me... you do like to :scratch: :scratch2: :D

NB: I if you haven't smilies enabled above does not make sense.
 
Asio

My card driver supports both ASIO and MME, and it's control panel has an explicit button to enable MME, which is off, by default. For some reason they seem to be enabled anyway, it seems. Other apps offer ASIO Control panels which seem to work.

- Klaus
 
And Ask,

pls don't forget a DUT response IMPORT option, for offline-processing and "raw" use of the convolver, since I intend to preprocess the DUT response if needed (you can see, I just want to abuse your programming skills to get around programming my own freq-domain convolver with partitioning and all the frills needed to make it run efficiently, ha-ha).

And take your time, no need to hurry.

- Klaus
 
KSTR said:
I would find file-I/O for everthing very useful (especially for offline processing) :
- stimulus (and the inverse, too, while you're at it)
- DUT's response
- impulse (that is, additional to the text export we already have)

Is the inverse really of any value if you have the stimulus? Does anyone besides Farina really bother to convolve with the inverse rather than simply do regularised division by the FFT in the frequency domain?

My preferred formats for all three would be
- plain array of raw double, .DBL (+ dialog for the samplerate, then), since that is as "lossless" as it gets
- 32bit float .WAV
- 24 oder 16bit int .WAV (w/ normalizing + dither, maybe)
And for the pulse an estimate (or the precise value) of the sample offset between harmonics.
Wouldn't float do the job as well as double, and at half the file size? Your sweep would need to run for hours (days? weeks? :)) to exceed the dynamic range of floats.
 
JohnPM said:
Is the inverse really of any value if you have the stimulus? Does anyone besides Farina really bother to convolve with the inverse rather than simply do regularised division by the FFT in the frequency domain?
Good point, I indeed intended to try other convolvers to look at the IR they would come up with and compare with Ask's result. From a practial standpoint FFT division would do for FR mag, for correct phase info we'd need to align the response first (or let the SW do that, like ie spectralab does). Also I could just derive the inverse from the stimulus (reversed and with the 6dB/oct mag correction) but there is some uncertainity and guesswork involved.


Wouldn't float do the job as well as double, and at half the file size? Your sweep would need to run for hours (days? weeks? :)) to exceed the dynamic range of floats. [/B]
float WAVs would suffice in term of precision, thats true. But I have SW's which only accept headerless raw double for input...

- Klaus
 
KSTR said:
Also I could just derive the inverse from the stimulus (reversed and with the 6dB/oct mag correction) but there is some uncertainity and guesswork involved.

Just do it in the frequency domain, FFT, element-wise reciprocal (regularised if stimulus content is band limited), IFFT, and the guesswork and magnitude corrections disappear. The whole reversal/magnitude correction thing is only the time domain approximation to the frequency division after all, but without the precision. :D
 
Thanks, John.... but I admit your short description is above my head, I'm just a lowly EE and not a math geek who a) fully understands signal theory in all its sublte details and b) is a MATLAB etc wizard. If I were I wouldn't have participated in this thread....

- Klaus
 
Regulized IFFT - bandpassed IFFT

Now please don't make this complicated

ref page 14 in:
http://pcfarina.eng.unipr.it/Public/Papers/238-NordicSound2007.pdf


The computation of the inverse filter is done in
frequency domain:
C[f] = Conj(H[f])/(Conj(H[f])H[f]+ε[f])
Where ε(f) is a small regularization parameter,
which can be frequency-dependent, so that the
inversion does not operates outside the frequency
range covered by the sine sweep


Without ε[f] we would simply have: C[f] = 1/H[f]
Applying ε[f] is nothing else than a bandpass of the resulting response. Like when Klaus is sweeping from 1000 Hz, then he knows that the response below 1000 Hz is not valid.

I'm in doubt if I should adopt this bandpass for the log-sweep - If I did Klaus and Earl would require that it could be disabled, so they could get the raw impulse ;)