Re: Re: Re: N'th Pre-Impulses timewindows
Yes, I see that now. One really needs to have a quieter room or anechoic to get good harmonic data no matter what technique is used.
Thanks
I hope you saw my post on the 64-bit version 2.0. Its still won;t run and the problem is the same as before - won't recognize my sound card. But what's curious is that the software did work at one time, but now none of the versions work anymore. I can't seem to get back to a functional system.
askbojesen said:
Yes, I see that now. One really needs to have a quieter room or anechoic to get good harmonic data no matter what technique is used.
Thanks
I hope you saw my post on the 64-bit version 2.0. Its still won;t run and the problem is the same as before - won't recognize my sound card. But what's curious is that the software did work at one time, but now none of the versions work anymore. I can't seem to get back to a functional system.
Re: Re: Re: Re: Re: N'th Pre-Impulses timewindows
My point was that first we need to know the distortion as it is manifested by the system in order to know IF it is an issue worth going after. Then IF it is, the logical thing would be to find the component(s) responsible (which is a different test). But the first assement must be that of the system. Just chasing numbers to chase numbers is a real waste of time.
soongsc said:
If we are not trying to improve a design, why would we even need to measure the distortion and harmonics figures?
My point was that first we need to know the distortion as it is manifested by the system in order to know IF it is an issue worth going after. Then IF it is, the logical thing would be to find the component(s) responsible (which is a different test). But the first assement must be that of the system. Just chasing numbers to chase numbers is a real waste of time.
look into my problem on Vista-64. I am dying to try your software, but it crashed in the middle of a big project and I'll only have the speakers for a few more days.So you say that you can not see your soundcard in the input devices? Since you are using DS instead of ASIO you will need to make sure that windows is setup properly - proper inputs/outputs assigned and the SAME samplerate as HOLMImpulse or else windows will resample (poorly) on the fly. Go to Control Panel>Sounds>Recording choose the inputs you want and set them as default then choose properties>Advanced and choose your samplerate or else you will get increased THD.
Also double check that nothing is disabled in the device manager - right click my computer>Device Manager.
If this doesn't work I would again recommend using ASIO4All. I could not get my Mackie 400f to work with ASIO and HOLM properly and I too am using ASIO4All as a workaround.
I don't think this is the fault of HOLM but the fault of the programing on my soundcards drivers. But maybe you should double check the i/o options Ask because all I get is "ASIO Onyx F Series" and not the individual inputs and outputs like I do with Right Mark Audio Analyser.
Oh another thing you might want to try E.G. go to C:\Users\All Users\HOLM Acoustics\HOLMImpulse and make a backup of those files. Then reinstall and start from scratch. Your settings will be lost though.
Also double check that nothing is disabled in the device manager - right click my computer>Device Manager.
If this doesn't work I would again recommend using ASIO4All. I could not get my Mackie 400f to work with ASIO and HOLM properly and I too am using ASIO4All as a workaround.
I don't think this is the fault of HOLM but the fault of the programing on my soundcards drivers. But maybe you should double check the i/o options Ask because all I get is "ASIO Onyx F Series" and not the individual inputs and outputs like I do with Right Mark Audio Analyser.
Oh another thing you might want to try E.G. go to C:\Users\All Users\HOLM Acoustics\HOLMImpulse and make a backup of those files. Then reinstall and start from scratch. Your settings will be lost though.
Not being a Windows sound card novice I've already done and tried all those things. In Vista, the directory for HOLM is not in "users", Vista doesn't do things that way any more. Those files are in "Program data". I have lots of other acoustic software on this same machine and none of it has any problems, only HOLM. The sound card is the one that comes with the machine so its not an add-on and the machine is an HP which is a pretty solid system from all that I can tell.
I sent Ask the error log which clearly showed that the system was returning an error when queried about the sound card. Something about the way this is done or the way the return eror is handled is not correct.
I sent Ask the error log which clearly showed that the system was returning an error when queried about the sound card. Something about the way this is done or the way the return eror is handled is not correct.
I am not sure all I can say is I don't have a problem on vista 64. And I do have the data in the "user" folder as well as the "ProgramData" folder but I installed 3 different versions so one of them might be left over. Did you uninstall the x86 version before installing the x64 version? I just assumed they all used the same folder since my settings remained in all 3.
I guess I could try it with my other 2 soundcards and make sure, it's just I never have good results with DirectSound. Running the same loopback test right now I see a lot more THD with DS i/o than with ASIO.
I guess I could try it with my other 2 soundcards and make sure, it's just I never have good results with DirectSound. Running the same loopback test right now I see a lot more THD with DS i/o than with ASIO.
Key said:
I did install the x86 version first. Its an odd thing, but my Vista won't let me, the administrator, look at the users directories. It says that I don't have permission. I saw that even the administrator was not allowed permissions for these directories, but the system would not let me add the administrator to view the directories. All very odd. Kind of a permission hell.
I am not an expert at Direct sound, but somehow I can't see how a hardware driver can have any effect on THD. Basically the sampling is done by the card and the Windows drivers, just access the samples.
Yeah I disable all that security bs.
In my case I believe the increased THD was because I was too lazy to change the settings in windows to 192kHz instead of 96kHz. My card and HOLM were at 192 but since windows does not switch clocks to accomidate different sample rates it just "resamples" on the fly.
In my case I believe the increased THD was because I was too lazy to change the settings in windows to 192kHz instead of 96kHz. My card and HOLM were at 192 but since windows does not switch clocks to accomidate different sample rates it just "resamples" on the fly.
Hmm it isn't the settings for the sample rate. Maybe a bitdepth issue?
DS=Blue
ASIO=Red
DS=Blue
ASIO=Red
An externally hosted image should be here but it was not working when we last tested it.
I have found the same issue with ASIO vs. MME/DS, albeit to a way lesser extent, see
http://www.diyaudio.com/forums/showthread.php?postid=1857553#post1857553
Sweep length and many other parameters all have influence on the results. I will try to make explicit HD measurements at fixed LF frequencies or with sweeps with other means to find what is the issue here -- OTOH in my setup it's not a big deal with that low THD levels, compared to any speaker (&mic&room)
In my cards two big ASICs take care of everthing, deriving an almost freely adjustable sampling rate from a 40Mhz oscillator.. so different traffic over PCI etc could easily modify the LF jitter spectrum which could then have an influence on HD the way Ask is calculating it. Not easy to identify...
- Klaus
http://www.diyaudio.com/forums/showthread.php?postid=1857553#post1857553
Sweep length and many other parameters all have influence on the results. I will try to make explicit HD measurements at fixed LF frequencies or with sweeps with other means to find what is the issue here -- OTOH in my setup it's not a big deal with that low THD levels, compared to any speaker (&mic&room)
In my cards two big ASICs take care of everthing, deriving an almost freely adjustable sampling rate from a 40Mhz oscillator.. so different traffic over PCI etc could easily modify the LF jitter spectrum which could then have an influence on HD the way Ask is calculating it. Not easy to identify...
- Klaus
HOLMImpulse @ Linux
The problem is that I use both C++ and CLR in windows
This means that in linux I'll have to choose between wine or mono
The ideal whould be mono with the C++ part compiled in native linux
and the CLR-windows only affecting GUI performance
I have been thinking about this... Maybe in a year ;-)
Elam said:Will there be a Linux/Mono version?
The problem is that I use both C++ and CLR in windows
This means that in linux I'll have to choose between wine or mono
The ideal whould be mono with the C++ part compiled in native linux
and the CLR-windows only affecting GUI performance
I have been thinking about this... Maybe in a year ;-)
New Release 1.2.0.2
http://www.holmacoustics.com/downloads/HOLMImpulse/ChangeLog.txt
Version 1.2.0.2 (2009-07-03)
Features/Changes:
* Reinitialize Audio library (Detects soundcards plugged after start)
* Show PortAudio device information button
* Frequency domain - Export as PSpice compatiable text-file
* Impulse domain - Impulse interpolation is now optional
* Improved inverse calculation
Bugfixes:
* Keep stream active while cannot restart stream
* Export Impulse domain text file has a header no matter what the "text" option is set at.
* Imaginary part of Nyquist frequency in 2^n FFT
Notes:
* SSE2-version is now enabled per default, so the specific SSE2 version is now dead.
Known bugs:
* Crashes at signal length = 21
* Make Dac-Adc calibration does not work
Upcoming features
http://www.holmacoustics.com/downloads/HOLMImpulse/Issues.txt
http://www.holmacoustics.com/downloads/HOLMImpulse/ChangeLog.txt
Version 1.2.0.2 (2009-07-03)
Features/Changes:
* Reinitialize Audio library (Detects soundcards plugged after start)
* Show PortAudio device information button
* Frequency domain - Export as PSpice compatiable text-file
* Impulse domain - Impulse interpolation is now optional
* Improved inverse calculation
Bugfixes:
* Keep stream active while cannot restart stream
* Export Impulse domain text file has a header no matter what the "text" option is set at.
* Imaginary part of Nyquist frequency in 2^n FFT
Notes:
* SSE2-version is now enabled per default, so the specific SSE2 version is now dead.
Known bugs:
* Crashes at signal length = 21
* Make Dac-Adc calibration does not work
Upcoming features
http://www.holmacoustics.com/downloads/HOLMImpulse/Issues.txt
Hello!
As you have seen in the other HOLM ｓｕｂｊｅｃｔ， Ｉ am trying to use your software to time-align drivers.
Today, I checked if a repeated measurement will have the same result.
I measured a single woofer, locked the time 0, at its IR's peak and then did other measurements with the exact same setup and of course without moving anything.
It appeared that the measurement number 1 (that is "empty 1' at the very beginning and becomes "Unnamed-1") seems to act strangely here.
If I measure using this measurement (number 1) the IR's peak is not always at time 0. When I repeat the measurement several times, the IR's peak position is between -0.02ms and 0.02ms...
The strange thing is that if I use other measurement file (like empty 2 ot other) and measure the same setup again. Then the IR's peak is always at time 0.
I tried to use the "number 1" file in other slot that its default slot B.
So I put that file in slot A and repeated some measurement again with the same setup: similar result: offset of +/-0.02ms. In slot C : same offset...
And I have tried other files in various slot: no offset!
That is weird, isn't it ?
Could that be a bug associated with this measurement file number 1 ?
Could that be a sound card related problem ?
I don't think so because, that would mean I would have been very lucky to have no offset with the measurement files other than number 1...
But about the sound card: how can we make sure it doesn't create an offset? I mean a variable offset, other than its latency...
Is the latency of a sound card always the same ?
As you have seen in the other HOLM ｓｕｂｊｅｃｔ， Ｉ am trying to use your software to time-align drivers.
Today, I checked if a repeated measurement will have the same result.
I measured a single woofer, locked the time 0, at its IR's peak and then did other measurements with the exact same setup and of course without moving anything.
It appeared that the measurement number 1 (that is "empty 1' at the very beginning and becomes "Unnamed-1") seems to act strangely here.
If I measure using this measurement (number 1) the IR's peak is not always at time 0. When I repeat the measurement several times, the IR's peak position is between -0.02ms and 0.02ms...
The strange thing is that if I use other measurement file (like empty 2 ot other) and measure the same setup again. Then the IR's peak is always at time 0.
I tried to use the "number 1" file in other slot that its default slot B.
So I put that file in slot A and repeated some measurement again with the same setup: similar result: offset of +/-0.02ms. In slot C : same offset...
And I have tried other files in various slot: no offset!
That is weird, isn't it ?
Could that be a bug associated with this measurement file number 1 ?
Could that be a sound card related problem ?
I don't think so because, that would mean I would have been very lucky to have no offset with the measurement files other than number 1...
But about the sound card: how can we make sure it doesn't create an offset? I mean a variable offset, other than its latency...
Is the latency of a sound card always the same ?
Time zero lock
That is why you MUST use keep-stream active when time-aligning
When keeping the full duplex stream active I'll only get offset-errors if the stream has dropouts. Because you are right the absolute offset changes a lot from time to time.
(Even for low-latency-ASIO you will get a few samples difference)
It is a very good idea to reproduce the impulse when timealigning, but don't use the woofer as reference, since the accuracy is proprotional to the frequency- hence a tweeter at 20000 Hz is 100 times more time-accurate than a woofer at 200 Hz
I suggest:
1. Keep stream active
2. Measure Tweeter
3. Use -> lock time zero
4. Measure Tweeter again same position (Reproduce IR)
5. Move the mic/speaker 1cm measure again, then you will see 1 cm translation of the IR
When above works, then you will know that you are on the right track
domtw said:
That is why you MUST use keep-stream active when time-aligning
When keeping the full duplex stream active I'll only get offset-errors if the stream has dropouts. Because you are right the absolute offset changes a lot from time to time.
(Even for low-latency-ASIO you will get a few samples difference)
It is a very good idea to reproduce the impulse when timealigning, but don't use the woofer as reference, since the accuracy is proprotional to the frequency- hence a tweeter at 20000 Hz is 100 times more time-accurate than a woofer at 200 Hz
I suggest:
1. Keep stream active
2. Measure Tweeter
3. Use -> lock time zero
4. Measure Tweeter again same position (Reproduce IR)
5. Move the mic/speaker 1cm measure again, then you will see 1 cm translation of the IR
When above works, then you will know that you are on the right track
I have made the experience again, after restarting the software.
This time, all measurements were similar (without offset)
I don't know what happened previously...
I get your point for the time accuracy of a twitter's IR but in practice, it is much easier to move the tweeter than the woofer...
And, at the end, we want to compare both IR so if one is the reference of the other or reciprocally, I would think that it doesn't make a difference...
Or am I forgetting something ?
This time, all measurements were similar (without offset)
I don't know what happened previously...
I get your point for the time accuracy of a twitter's IR but in practice, it is much easier to move the tweeter than the woofer...
And, at the end, we want to compare both IR so if one is the reference of the other or reciprocally, I would think that it doesn't make a difference...
Or am I forgetting something ?
Numerical test of the logsweep
I have made some "debug" numerical analysis.
"Measurements" can be downloaded here:
http://www.holmacoustics.com/downloads/HOLMImpulse/notes/NumericTest/NumLoopBack.hlm
Untill I implement the load DUT response you can not make these measurements yourself.
Parameters not changed:
Samplerate = 44.1 kHz
Frequency start = 10Hz
L = 18 & L = 19
First compare two different lengths L = 18, 19 (6 sec, 12 sec)
The noise level for the impulse response is around -180dB (10^-9)
This give a relative THD sum around -140 dB.
Observations:
- No difference with the noise level for L = 18,19
- No artifacts
- Uniform noise level for the entire impulse range
- Nearly uniform frequency noise level
- IR Noise level : -180 dB
- FR Noise level: -140 dB
There are absolutely NO artifacts, which is seen on a zoom around the Dirac sample:
THD when fading
Introducing THD by making clipping (amplify by 1,25 and truncate) L = 18
Observations:
- If to much fading then THD is not relieable
- Same THD level in the "safe" non fading zone
- Same trend in IR
THD when using L = 18, 19
Introducing THD by making clipping (amplify by 1,25 and truncate)
This is a beauty, same THD when using L = 18 or L = 19
Inverse when fading
Observations:
- Fading to much gives an "ugly" inverse signal, which might introduce artifacts when using narrow timewindows
Conclusions
- No numerical artifacts
- IR noise level: -185 dB
- THD noise level: -140 dB
- Unform noise in the IR
- Unform noise in the FR
- Fading does not improve anything
Disable fading in future releases?
Why do I want to do this?
Fading disadvantages:
- Why complicate matters if you do not know what you get?
- The inverse is not uniquely determined by: Length, Samplerate, frequency start. Eg. burning to a CD or record we will not know "which" kind of fading that we used.
Fading advantages:
- To be numerically justified
(When measuring soundcard loopback we do not know what we must get - we are only guessing)
Does anybody have an idea when fading will improve the data?
I mean what kind of input distortion / transfer function should I introduce numerically?
I have made some "debug" numerical analysis.
"Measurements" can be downloaded here:
http://www.holmacoustics.com/downloads/HOLMImpulse/notes/NumericTest/NumLoopBack.hlm
Untill I implement the load DUT response you can not make these measurements yourself.
Parameters not changed:
Samplerate = 44.1 kHz
Frequency start = 10Hz
L = 18 & L = 19
First compare two different lengths L = 18, 19 (6 sec, 12 sec)
The noise level for the impulse response is around -180dB (10^-9)
This give a relative THD sum around -140 dB.
Observations:
- No difference with the noise level for L = 18,19
- No artifacts
- Uniform noise level for the entire impulse range
- Nearly uniform frequency noise level
- IR Noise level : -180 dB
- FR Noise level: -140 dB
An externally hosted image should be here but it was not working when we last tested it.
There are absolutely NO artifacts, which is seen on a zoom around the Dirac sample:
An externally hosted image should be here but it was not working when we last tested it.
THD when fading
Introducing THD by making clipping (amplify by 1,25 and truncate) L = 18
Observations:
- If to much fading then THD is not relieable
- Same THD level in the "safe" non fading zone
- Same trend in IR
An externally hosted image should be here but it was not working when we last tested it.
THD when using L = 18, 19
Introducing THD by making clipping (amplify by 1,25 and truncate)
This is a beauty, same THD when using L = 18 or L = 19
An externally hosted image should be here but it was not working when we last tested it.
Inverse when fading
Observations:
- Fading to much gives an "ugly" inverse signal, which might introduce artifacts when using narrow timewindows
An externally hosted image should be here but it was not working when we last tested it.
Conclusions
- No numerical artifacts
- IR noise level: -185 dB
- THD noise level: -140 dB
- Unform noise in the IR
- Unform noise in the FR
- Fading does not improve anything
Disable fading in future releases?
Why do I want to do this?
Fading disadvantages:
- Why complicate matters if you do not know what you get?
- The inverse is not uniquely determined by: Length, Samplerate, frequency start. Eg. burning to a CD or record we will not know "which" kind of fading that we used.
Fading advantages:
- To be numerically justified
(When measuring soundcard loopback we do not know what we must get - we are only guessing)
Does anybody have an idea when fading will improve the data?
I mean what kind of input distortion / transfer function should I introduce numerically?
I think I cannot give a satisfying answer for the fading issue... but I share a few thoughts and observations, adding to what I already wrote in an earlier post.
The "problem" lies in the way you define the inverse as the inverse of the sweep in the freq domain regardless of its shape (enevelope), which gives by definition a true dirac unless you run into numerical issues.
However, all sources I checked (DRC especially) generating bandlimited(!) log sweeps and their inverses handle it different, the convolution "back into the pulse" shows exactly that bandlimiting in the pulse also, hence not a "perfect" dirac. And all use raised-cosine or similar low-sideband windowing (DRC: Blackmann) for the fades. I use raised-cosine in my own code and get almost pefectly consistent results with DRC. Point is that these windows are applied to the inverse as well, additional (multiplying) to the overall log fade which makes the inverse just as "perfect" as the stimulus. Both are generated in the time domain. And the fades are included in the total sweep time and total freq range.
In your case the fades sort of pre-equalize the stimulus but your inverse cancels that, forcing a flat response. Therefore, during the fades, it is obvious that there are differences in the distortion as the signal level changes, transparent to the process the way you do it. Not regarding the distortion coming from the kink in the waveform with the window you use (which you might have changed in the meantime, I didn't check this).
While I understand there are good reasons for either way, I'd basically prefer the non-transparent approach, any intentional bandlimiting shall be seen (in your SW as the "measurement signal"). Except for the case of a bit of HF attenuation to protect the tweeter better during a fullrange measurement. That is what Uli Brueggemann does in his log-sweep recorder. He also has a stop freq, which is a nice feature when one is using higher sample rates, for example. Further there are "markers" in front of the sweep and behind it, to be able to compensate clock-mismatches to a certain extent when using non-synced recording.
OTOH this makes mic and adc/dac calibration different...
------:-------
All the other stuff is fine, I did a few real speaker measurements today and the handling of the SW is really excellent now.
- Klaus
The "problem" lies in the way you define the inverse as the inverse of the sweep in the freq domain regardless of its shape (enevelope), which gives by definition a true dirac unless you run into numerical issues.
However, all sources I checked (DRC especially) generating bandlimited(!) log sweeps and their inverses handle it different, the convolution "back into the pulse" shows exactly that bandlimiting in the pulse also, hence not a "perfect" dirac. And all use raised-cosine or similar low-sideband windowing (DRC: Blackmann) for the fades. I use raised-cosine in my own code and get almost pefectly consistent results with DRC. Point is that these windows are applied to the inverse as well, additional (multiplying) to the overall log fade which makes the inverse just as "perfect" as the stimulus. Both are generated in the time domain. And the fades are included in the total sweep time and total freq range.
In your case the fades sort of pre-equalize the stimulus but your inverse cancels that, forcing a flat response. Therefore, during the fades, it is obvious that there are differences in the distortion as the signal level changes, transparent to the process the way you do it. Not regarding the distortion coming from the kink in the waveform with the window you use (which you might have changed in the meantime, I didn't check this).
While I understand there are good reasons for either way, I'd basically prefer the non-transparent approach, any intentional bandlimiting shall be seen (in your SW as the "measurement signal"). Except for the case of a bit of HF attenuation to protect the tweeter better during a fullrange measurement. That is what Uli Brueggemann does in his log-sweep recorder. He also has a stop freq, which is a nice feature when one is using higher sample rates, for example. Further there are "markers" in front of the sweep and behind it, to be able to compensate clock-mismatches to a certain extent when using non-synced recording.
OTOH this makes mic and adc/dac calibration different...
------:-------
All the other stuff is fine, I did a few real speaker measurements today and the handling of the SW is really excellent now.
- Klaus