That does raise the question of an appropriate file format, there's none suitable that already exist AFAIK.
Some kind of extension of FRD with r, theta, phi data.
Anyone know details of the HolmImpulse format that Earl uses? He hasn't answered my last few questions.
Best wishes
David
holmimpulse lets you export to a single file in the following format
Code:
# First sample number in file: -10000
# Last sample number in file: 10000
# Samplerate: 48000
#
## sample;0 (Import: woofer_mp.frd) ;1 (Import: cd_mp.frd)
-10000;5.6496302941e-007;2.2383797616e-005
-9999;5.77869767557e-007;-2.21340868047e-005
-9998;5.37885862763e-007;2.2304279733e-005i.e. there are n+1 attributes per row (where n is the no of measurements)
I think ARTA has an automated polar measurement thing, see AP9 in ARTA Support
I have never used a USB microphone so I can't comment. I do use a Behringer USB sound card and have only fleeting trouble with time sync. It can completely loose sync at times, but 80% of the time it is fine. I have never seen a slow drift in time sync with my card.
It seems to me that 400 points is an absurd goal. I do full horizontal polars with 13 points, doing verticals would add only about another 10. A full spherical scan should be doable with < 50 points.
It seems to me that 400 points is an absurd goal. I do full horizontal polars with 13 points, doing verticals would add only about another 10. A full spherical scan should be doable with < 50 points.
I import Holm impulses. The windowing should be done in the analysis software NOT in the data acquisition software. What is shown above is correct, except that 20000 samples is almost 10 times too many.
I once saw Holm drop a few samples - only once - so my software checks the sample numbers for continuity. Have not seen it happen again in hundreds of runs. But it was catastrophic when it happened.
I once saw Holm drop a few samples - only once - so my software checks the sample numbers for continuity. Have not seen it happen again in hundreds of runs. But it was catastrophic when it happened.
Hi Guys,
I don't have any experience with octave, but with Matlab you certainly can do everything that' s needed.
I wrote my own measurement suite (like holm, but with more specialized things for my work) in matlab, it' s relatively easy to make the mathematic side of the things in matlab (much more easy than in python or C# etc.), only a nice interface is a lot of work. Most users including myself use Matlab without interface, which is not too user friendly if you didn't make the code yourself.
I think that the thing with octave is that you don't have nice ASIO sound card driver support etc, but I'm not sure, maybe someone has experience with this.
I guess that octave is pretty much code-compatible with matlab as long as you don't use special functions from matlab (like libraries to communicate with databases), but again I am not sure.
If the Matlab route is chosen (or octave is compatible enough), I will gladly donate the part of my code which does the actual measurement (through swept sine method just like holm/rew), as I like this project.
I could also help implement the math in matlab, but I would need some pseudo code description as I am not at all at home in the mentioned math, and don't have the time to get into this.
cheers,
Kees
I don't have any experience with octave, but with Matlab you certainly can do everything that' s needed.
I wrote my own measurement suite (like holm, but with more specialized things for my work) in matlab, it' s relatively easy to make the mathematic side of the things in matlab (much more easy than in python or C# etc.), only a nice interface is a lot of work. Most users including myself use Matlab without interface, which is not too user friendly if you didn't make the code yourself.
I think that the thing with octave is that you don't have nice ASIO sound card driver support etc, but I'm not sure, maybe someone has experience with this.
I guess that octave is pretty much code-compatible with matlab as long as you don't use special functions from matlab (like libraries to communicate with databases), but again I am not sure.
If the Matlab route is chosen (or octave is compatible enough), I will gladly donate the part of my code which does the actual measurement (through swept sine method just like holm/rew), as I like this project.
I could also help implement the math in matlab, but I would need some pseudo code description as I am not at all at home in the mentioned math, and don't have the time to get into this.
cheers,
Kees
My 2 cents is that the data taking and the analysis have to be two separate implementations/ apps. The user must be free to use whatever hardware and software they deem satisfactory to get the N impulse responses. Then the analysis software must read these N signals and compute the best possible fit to whatever points the user chooses. I can do this now with my software so its perfectly doable. Once you have the analysis code it makes no difference to the code how many points or where they are. It just gives you the best fit that it can get from the data supplied. Some point locations and numbers will yield better results than others, so some work on "optimization" (like I did, should be done.)
I use this convergence of results all the time to find the number of modes required. When the results cease to change as N is increased it means that it has converged. You don't need any more points than modes as its a linear problem of N unknowns with N data points. I find 12-15 points is this convergence at 10 kHz. If we add M points around the axis then we have M x N points and potential modes, but M would never be more that say 6 at best, so 6 x 15 = 90 is the maximum points that I could ever see in even the worst possible case. I would bet its a lot lower than that.
I use this convergence of results all the time to find the number of modes required. When the results cease to change as N is increased it means that it has converged. You don't need any more points than modes as its a linear problem of N unknowns with N data points. I find 12-15 points is this convergence at 10 kHz. If we add M points around the axis then we have M x N points and potential modes, but M would never be more that say 6 at best, so 6 x 15 = 90 is the maximum points that I could ever see in even the worst possible case. I would bet its a lot lower than that.
Thanks for that information
I have taken Klippel's numbers to provide an order estimate.
Their poster and presentation both show >1000 points for maximum details, between 1000 and 100 for accurate work.
The presentation shows two case studies.
One is 4000 points, presumably as an extreme example.
The second is 500 points.
So 400 points doesn't look absurd to me, at ~10 seconds/data point that's about an hour measurement, not absurd for time.
Whether it's absurd for other reasons I don't yet know.
Until I have it clear in my mind I am inclined to assume Klippel have had some experience and their numbers are in the ballpark.
Octave is supposed to be compatible with Matlab, if Matlab code won't work in Octave then this is reportable, should be fixed.
So we should be OK.
Thanks for the offer, I would like to work with you if I finally work out the maths nice and clearly.
Best wishes
David
Last edited:
Naturally, the optimization becomes harder for the 3D problem rather than just the horizontal polar that you did.
I am currently at work on this but it's one of the bits that's not clear to me.
"M points around the axis" is more or less the point of the project, so not much "if" about that.
I assume that resolution in both axes should be similar and the limited literature I have read usually takes M about the same as N.
So I think more like 15 x 15, I took N to be 20, hence my 400 ballpark number.
That's to check that measurement time is feasible, practicality of file formats and so on.
As I noted in the previous post, it's more or less in line with Klippel's numbers so I expect it's not too unreasonable but I don't have the details clear.
Have you looked at the Klippel presentations?
Why do you think their number is so much more than your bet?
Best wishes
David
Last edited:
I haven't gone through the articles linked here, which seem to be an advanced subject indeed. However, one thing I should mention is that if one's goal is to do correct complex summations of measurements taken with an acoustic timing reference in REW, such measurements must have all been taken at the same measurement position. That's because, with an acoustic timing reference, the reference itself changes if the measurement position changes.
The reason the acoustic timing reference works properly with e.g. MSO is that all complex summations in that software are done with the mic in the same position (assuming the project has been set up correctly). One cannot do complex summations of data taken at different measurement positions without error when using an acoustic timing reference in REW. In order to do such complex summations correctly when measuring with REW, one must use a true loopback timing reference.
not up to the math but I can search:
'python spherical harmonics'
turns up SHTOOLS package Fortran/Python, and this page gives some gridding refs
Implementation details | SHTOOLS - Tools for working with spherical harmonics
'python spherical harmonics'
turns up SHTOOLS package Fortran/Python, and this page gives some gridding refs
Implementation details | SHTOOLS - Tools for working with spherical harmonics
Exactly so, I can't see it could work for the 2 layer scan but I didn't even want to think about it, so thanks for the confirmation.
We are locked in to loop-back reference, REW or Arta are OK but I think this eliminates HolmImpulse.
Best wishes
David
Last edited:
Hmm, the problematic TI PCM29xx used for your UCA202 is limited to 48 kHz and some of the newer USB sound cards are 96 kHz or more, so presumably use a different codec.
I wonder if they fixed the problem? I am reluctant to use any "it mostly works" solutions.
May as well stay with REW and avoid the sync problem.
There's some USB sound cards that look suitable for this project, with 2-in 2-out to handle loop back, plus built in phantom mike power and pre-amp so less complication from add on boards.
There's a new Behrin*er, or the Focusrite Scarlett looks decent and only ~$50 more.
Any one tried either? Or have a better recommendation?
Best wishes
David
I have a focusrite scarlett, seems fine to me. There are measurements for it shown at Focusrite Scarlett 2i2 IIRC there is a 2nd gen version available now which behaves in a v similar way.
Yes
Its because he uses a sweep and with a sweep, the number of points is not an issue so why not use more. With a manual setup this is the exact opposite - it is critical to minimize the number of points.
This project is getting ever further away from what I had envisioned, which was a simple DIY setup that could be done by DIYs using inexpensive setups. I am not interested in helping to make a system that is complex, expensive and uses anything proprietary, such as a single measurement piece of software.
LIGO "runs" on Python BTW. All this one language vs another on speed please don't lose sight of the fact that they are all operating on the same processor. Every language platform appeals to a different user base, IME the optimizers on C compilers are often not very good for raw floating point speed. In fact I used one years ago that ignored the 8 80bit floating point registers available in the CPU and I had to use in line assembler as a work around. The speed up of complex number multiplies was dramatic.
I know you guys are doing some esoteric stuff but I find it hard to believe that the Python community has missed much of anything that is available in Matlab.
The Scarlett is fine but on Windows always verify that the noise floor goes to fs/2 and the LSB is 24bit not 16. When things revert to 44.1/16 usually there is no warning.
movie of the pattern the klippel system makes:
UPstage 360｜World's First 360deg Smart Speaker in Hi-Res Audio by Level 10 —
Kickstarter
I have to admit that I am totally fascinated by the realization that you can make good measurements in such a small, untreated room. You can hear how typical the room sounds on the video, normally you would not be able to measure anything decent below 300Hz
UPstage 360｜World's First 360deg Smart Speaker in Hi-Res Audio by Level 10 —
Kickstarter
I have to admit that I am totally fascinated by the realization that you can make good measurements in such a small, untreated room. You can hear how typical the room sounds on the video, normally you would not be able to measure anything decent below 300Hz
I see simple and inexpensive as the objective and non-proprietary as desirable mainly as a way to achieve that.
Unreliability is a cost and you yourself wrote about HolmImpulse -
Inevitably a full 3-D measurement will take more time than just a horizontal polar so the chances of a loss of sync increase and so does the cost in terms of time lost and frustration.
It's simpler just to use the more reliable software and I prize simplicity so that eliminates HolmImpulse for me.
Especially when there is no trade-off in expense - because REW is free.
Anyone is free to choose whatever software they want, I just plan to use REW.
Best wishes
David
Last edited: