No it's not, since USB audio interfaces have a balanced input (xlr).If the amplifier is bridged there is no ground at the output terminals and it is problematic
Something that has never been updated in the ARTA manual.
Also things like impedance measurements work perfectly fine with bridged amplifiers.
ARTA's manual still assumes that people use an old fashioned single ended soundcard input.
Btw, measuring with balanced inputs is always preferred, even with a grounded amplifier.
Since a bridged amplifier is nothing more than a balanced power driver, it's probably even preferred.
Having a fully balanced system can be beneficial against noise.
Last edited:
So here the proper global schematic for a balanced (bridged) output and balanced inputARTA describes two types of dual channel measurements
What they call dual channel takes the output from the amplifier with a voltage probe.
If the amplifier is bridged there is no ground at the output terminals and it is problematic.
View attachment 1285406
https://www.htguide.com/forum/articles/do-it-yourself-diy/927384-dual-channel-measurement-jig
What many people call dual channel, ARTA classifies as semi dual channel, where the loopback is just the line level output from the soundcard.
This causes no problems.
View attachment 1285407
The resistor divider is not really necessary, since most good quality audio interfaces can handle something like 7-10Vrms input + have a input gain knob (= attenuator)
Since they also can handle the 48V phantom power for microphones, this also automatically means they are protected for at least 50Vdc (poor quality) but more often 63Vdc.
The mic preamp is obviously build inside the mic itself and being fed by the phantom power and has a balanced output.
I'm choosing my battles and am gonna skip the full dual option for now.
@mbrennwa : I would like to be able to import the measurements into REW. It seems .wav file are used for impulse response measurements. Does MATAA support writing them in a way REW understands? REW can import FRD, but further processing is limited(/absent?).
@mbrennwa : I would like to be able to import the measurements into REW. It seems .wav file are used for impulse response measurements. Does MATAA support writing them in a way REW understands? REW can import FRD, but further processing is limited(/absent?).
Well, this is hardly a battle?I'm choosing my battles and am gonna skip the full dual option for now.
Just a matter of one cable going into an audio interface?
ehm? That was not the point at all? So totally not relevant.You're free to do it your way. I'm doing it my way.
You were first saying that it wasn't possible and secondly saying that it is difficult.
All I am showing that both aren't true.
That has nothing to do with personal taste, preference or the way someone likes to do things.
Besides, if we talk in a sense of making a Klippel NFS system, I can already tell that the very vast majority of people would like to have a dual channel system anyway or at least very much want that option.
If we want to provide a solution that can also be used for other people as well, I think it's extremely important to keep in mind what other people would like to use as well.
Or in fact is the standard these days when it comes down to dual channel measurements.
I'm choosing my battles...
Not sure what the advantage of using REW for the data processing would be (seems like a lot of extra complication), as Octave/Matlab will surely allow you to do a lot more than REW. The MATAA tools may be useful for that, but you're not limited those.@mbrennwa : I would like to be able to import the measurements into REW. It seems .wav file are used for impulse response measurements. Does MATAA support writing them in a way REW understands? REW can import FRD, but further processing is limited(/absent?).
Of course you can export your data for use with other software. MATAA has a tool to export TMD files (just time-domain ASCII data), but I have no clue if REW supports these. For WAV export you don't need any of the MATAA tools because that's available from Octave/Matlab directly: https://docs.octave.org/v4.2.1/Audio-File-Utilities.html
I'm trying to output raw measurements for people that use other software to process them. Up to now I like REW, Earl is a Holmimpulse fan, others use ARTA or Vituixcad. For the latter the mataa FRD export is very nice.Not sure what the advantage of using REW for the data processing would be (seems like a lot of extra complication), as Octave/Matlab will surely allow you to do a lot more than REW. The MATAA tools may be useful for that, but you're not limited those.
I'm also planning to import files, at least for 2D mode fitting and interpolation. For 3D, but that will take a while, klippel's format might be nice.
I know I can export .wav using Octave. I just have to find out what convention programs use, e.g. which channel is the reference. Should be no problem, but I have enough other stuff that I don't seek to duplicate existing functionality. Although... it helps me in learning and understanding things.
What's wrong with keeping the data in Octave for automated processing and plotting? I feel that's 1000x more convenient than exporting the data to many files, importing each file to some other software, and process each and every file there, possibly manually.
Also, the Weinreich sound field separation will not be available in REW or similar software anyway. Octave/Matlab would be a good platform for this.
Also, the Weinreich sound field separation will not be available in REW or similar software anyway. Octave/Matlab would be a good platform for this.
Nothing wrong with Octave. In fact NTK (& kessito) already implemented SFS in Octave.
I would like to offer data exporting for people that like a program they're currently using or to use features already implemented in other programs while I'm working on something else.
I would like to offer data exporting for people that like a program they're currently using or to use features already implemented in other programs while I'm working on something else.
What's wrong with keeping the data in Octave for automated processing and plotting? I feel that's 1000x more convenient than exporting the data to many files, importing each file to some other software, and process each and every file there, possibly manually.
So you're simply making sure the data from your system can be exported to other tools, just in case? THAT makes sense.I would like to offer data exporting for people that like a program they're currently using or to use features already implemented in other programs while I'm working on something else.
I pushed the current (limited alpha) state to github: https://github.com/TomKamphuys/Audio
The brave and impatient could try to use it.
The brave and impatient could try to use it.
[off topic on]barely anyone is using it
The Debian statistics indicate that Octave is installed on 1.6% of their machines alone. My guess would be that REW or any of the other audio test suites are installed on way less than 0.1% of the computers out there.
[off topic off]
That is a weird way of mixing statistics?[off topic on]
The Debian statistics indicate that Octave is installed on 1.6% of their machines alone. My guess would be that REW or any of the other audio test suites are installed on way less than 0.1% of the computers out there.
[off topic off]
And 100% of the users that use Octave are into audio, specifically into measuring loudspeakers?
And what is the percentage of Linux users compared to Windows users?
But I know something, just put out a poll, and ask how many people know Octave and work with it on a regular basis.
I would support mbrennwa's position. Octave is the way to go. My opinion on software is irrelevant at this point as I am not about to go out and learn new software or anything else. But clearly a wide applicability software like Octave is the best bet.
It's too bad that Mathmatica is not free, because I liked it a lot.
It's too bad that Mathmatica is not free, because I liked it a lot.
Cart before the horse?
If you are just into measuring commercial speakers like Erin, then Octave alone is the way to go.. but I suspect that most will want the ability to easily export their data to another program for modeling (almost certainly VituixCad for the vast majority interested in this sort of thing).
Tom is correct: export to other programs (modeling program’s in particular) should be the priority. After that, sure Octave (for those that want to put in the extra development).
If you are just into measuring commercial speakers like Erin, then Octave alone is the way to go.. but I suspect that most will want the ability to easily export their data to another program for modeling (almost certainly VituixCad for the vast majority interested in this sort of thing).
Tom is correct: export to other programs (modeling program’s in particular) should be the priority. After that, sure Octave (for those that want to put in the extra development).
Last edited:
Depend’s on the Audio Interface and particularly the desired input for that Audio Interface. Notably most will want the by-passed input that does not offer attenuation...most good quality audio interfaces can handle something like 7-10Vrms input + have a input gain knob (= attenuator)
I knew responding was a bad idea but I did it anyway, silly me. That situation is now rectified and you hold the bronze medal position on my ignore list.No it's not
- Home
- Design & Build
- Software Tools
- Klippel Near Field Scanner on a Shoestring