Very cool.
@HenrikEnquist and @SeaShell,
Thank you both for your excellent work. Very impressive.
I managed to get sample rates changing for [44.1-384]kHz content and also transcoding DSD to PCM and then passing it though the auto sample rates using FLOAT64LE "/path/filtername_$samplerate$.dbl" RePhase FIR filters.
The Loopback/ALSA_CDSP asound.conf configurations appear to be mutually exclusive so I stopped trying to combine them.
Now for some listening once the house gets quiet and possibly some more configuration cleanups.
Again, thank you for the great work.
Last edited:
Agreed, if the baseline isn't correct, then nothing else will be.
FWIW, here are the loopback measurements of all of my Sabre DAC's rolloff filters.
Focusrite 8i6 sound card USB out -> PC/REW USB out -> DAC balanced analog out -> Focusrite 8i6 USB sound card balanced input
Last edited:
Here it is- dead simple:-
I have been using this for years.
It works.
The little "glitches" you see above are in fact just display difficulties. There are no problems at all with the file.
I analysed levels recorded with Steinberg on each occasion to be sure. You can use their FFT tool to confirm the results of any notch & check levels.
They are 100% valid.
I have no doubt whatsoever measuring mic levels & loop back tests from both external DACs and with input connected to the card's output with their program is 100% correct.
I do,
Steinberg confirmed the recording levels. When you copy+paste the reference scan file in the left channel, and put the recorded audio file in the RH channel. You then have an exact comparison in one stereo file.
When you play back files, the levels are displayed in the "master" section playback read out in real time.
If there is any variation you will see it instantly.
This is what REW SPL says once you size it up to display 20-20khz and make some sense of it with the +/-- scale bar on the top LH corner:-
In practice any comparisons of levels I have made with it, I always align at identical levels (for what it's worth) at 1khz.
It is REW that is manifestly blatently incapable of dealing with importing a professional .wav file properly, and/or displaying it correctly.
It displays this ****-eyed graph, although the levels shown are in fact correct.
I stand by that.
What you see is what you get.
Attachments
Last edited:
It is actually interpreting the file correctly, here is an example of a 16 Hz to 22K log sweep generated with Audacity and the Frequency analysis of it. REW gives exactly the same when imported as audio.
A sine sweep and recorded response can be loaded into REW from the import sweep recordings option but it only works with sweeps made by REW's own generator.
REW is an awesome program that does most things related to measurements really well, it is written by a very knowledgeable and helpful person much like yourself.
Attachments
I have to ask WHY??
ie. It does everything well EXCEPT what is really useful.
A little documentation or warning on the lines of...."duh this program will not work at all with ....audio files of type "x y or x, produced by any other pro audio program ",
it doesn't work on Linux....and never will...etc..
"it's not standards based" etc etc
In other words REW might be fun, but it's no use at all to professionals, ...
but there we live and learn don't we (?) including the Linux professional audio card driver fiasco of the last couple of months...
which has taken an age to figure out. ahum!
True, it measures the frequency content of any imported file properly. But what I meant is that the interpretation as a measurement sweep isn't working, which is because sarcatic1 is using it wrong.
I have to ask WHY??
ie. It does everything well EXCEPT what is really useful.
A little documentation or warning on the lines of...."duh this program will not work at all with ....audio files of type "x y or x, produced by any other pro audio program ",
it doesn't work on Linux....and never will...etc..
"it's not standards based" etc etc
In other words REW might be fun, but it's no use at all to professionals, ...
but there we live and learn don't we (?) including the Linux professional audio card driver fiasco of the last couple of months...
which has taken an age to figure out. ahum!
REW is a tool, and like any tool you have to use it properly. I think perhaps also the professionals need to read the documentation
To get the proper timing info etc it needs to use it's own sweeps, which have timing marks needed to get the absolute delay right.
Here is the procedure to make proper measurements:
Step 1: Generate the sweep with REW itself.
- Go to Tools/Generator
- Set it to Meas. Sweep, and enter suitable datails below. Click the WAV button, make sure the "Add timing reference signal" is checked. Ok to save as a wav.
Step2: Make your measurements.
Step3: Import measurements into REW.
- Go to File/Import/Import sweep recording
- Click "Browse to select the previously exported wav in the upper box, select the Left channel (this is where we put the timing reference)
- In the lower box, do the same but select the recorded measurement instead. Also pick left channel.
Then REW will import and show exactly what it should.
I'm not doing anything of the sort.
Let's take note,-
1/ REW does NOT work on Linux, so if you don't have camillaDSP working on Windows, you won't get a valid in/out trace as described above back from the speakers or I/O from the sound card using the DSP.
Use Audacity on Linux, it's not going to help you, as I found out too.
2/ Testing & evaluating a piece of software, entails a "valid" validation strategy.
When for some reason or other it doesn't do what is expected, that's where those maybe with interest in making a finished product, are likely to get concerned.
Being as I could be likely to use Camilla as part of what will be an outstanding commercial product, I have every right to know what can/could go wrong.
It's free software.
Like most GNU stuff, an integrator then has to make with that modular approach work.
3/ So far we have evaluated this DSP in a "live" pro environment (with an audience), only to realise now, things are not quite functioning as expected, and one of the people present remarked on this "missing element", but we didn't know what it was.
Has anyone else done that?
If for some reason you think evaluation and validation strategies have no part in this thread, maybe one of us is wrong.
So far, the reactions from Henryk both in public and private appear to confirm I'm doing nothing wrong.
Pointing the finger at a certain part of the validation chain (OS related) or (Platform related) is part and parcel of debugging the whole chain.
I have now spent so many happy hours rebooting a multi boot notebook that I might not be talking rubbish** by now...
How many people have 3-4 working camilla DSP installations in the same room on 2-3 different computers with 2-3 different flavours of the same OS, & multiboot both 32 and 64 bit?
+
Have access to the local national opera house studio inventory of DPA, Neumann & Gefell mics...etc etc..
I sign off.
No real point after that comment in following or contributing to the thread any more.
Last edited:
I have used Camilla in OS X and done EQ with both for and iir and my measurements correlate with the EQ perfectly. So has many others on different platforms. With all due respect, I think you will not find an error in Camilla that is the source of your problem. You are not acting very professional.
//
//
thanks
REW Linux installer (requires Java 8) V5.20 RC5
So we have to revert to an earlier version of Java.
Most info here
That sums it up for the RPi.
Having found the bug on the Linux pro sound card driver on Linux x86, was quite a suprise.
REW on Linux may or may not have helped in that quest. (I used Steinberg).
I would suggest it IS a professional approach that refuses to give up, when a measurement made with a DAW doesn't match what the DSP should do.
This mismatch triggered these 2 months of investigation.
Last edited:
Linear vs. logarithmic sweeps 4M samples long (generated in audacity), analyzed by 4M FFT in REW (in linux of course).
Logically a log sweep will have less energy in the higher bins of the linearly-spaced FFT (which REW and most other packages do). FFT can be computed with log-spaced bins e.g. in matlab/octave.
Linux REW has its limits raised (max FFT 4M, max samplerate 1,536kHz). It is distributed as a regular jar + aux files bundle, unlike the windows one large exe file with embedded JRE8. That allows running REW jar with the latest java (and latest speed/garbage collector improvements), I tested java 14 a year ago https://www.diyaudio.com/forums/sof...stortion-measurements-rew-32.html#post6130483 .
Logically a log sweep will have less energy in the higher bins of the linearly-spaced FFT (which REW and most other packages do). FFT can be computed with log-spaced bins e.g. in matlab/octave.
Linux REW has its limits raised (max FFT 4M, max samplerate 1,536kHz). It is distributed as a regular jar + aux files bundle, unlike the windows one large exe file with embedded JRE8. That allows running REW jar with the latest java (and latest speed/garbage collector improvements), I tested java 14 a year ago https://www.diyaudio.com/forums/sof...stortion-measurements-rew-32.html#post6130483 .
Attachments
REW DOES work on Linux, it is running fine on my computer (just use proper java provider). John Mulcahy is very helpful, he responded even my super stupid question related to TRRS jack.
Describe your problems here Official REW (Room EQ Wizard) Support Forum | AV NIRVANA
Describe your problems here Official REW (Room EQ Wizard) Support Forum | AV NIRVANA
Sorry for being so late with this question:
I would like to early intercept every change of $channels$, $format$ and $samplerate$. The purpose would be to trigger some external routines, even before the changes are handled further to camilladsp, this is, before camilladsp starts anew with the updated values.
There is the config_cmd method which could do the job. But maybe there is a more elegant solution.
I'm not sure which version of Linux you are using.
I tried all sorts of methods, but you can't get the correct java 8 to run on my latest (buster) x86 version, and REW demands it.
I did check, and spent many happy hours struggling.
On each occasion I did, it suddenly appears any current Java version deprecates x86 and attempts to install an AMD64 version.
That was not made clear in the above posts.
When you go the official distro, it installs Java v11.
ie. openjdk 11.0.9.1 2020-11-04
OpenJDK Runtime Environment (build 11.0.9.1+1-post-Debian-1deb10u2)
OpenJDK Server VM (build 11.0.9.1+1-post-Debian-1deb10u2, mixed mode, sharing)
It hadn't occcured to me, the JavaVM in the windows version came packaged with the installation, neither did the (now obvious) incompatibity between linear and log transforms used on REW, compared with those created by just about any audio program I can think of , Avid, Steinberg, Cool, SF, Audacity etc...
Cool edit pro integrated Bologna university's (Angelo's) convolution work since years ago now.
(of course studio programs implement their own in proprietory tech).
How it used to be done.
All historic pro work on acoustic spaces used (an expensive) sonometer + impulses you created, which via a PDA or other interface used to export .csv files which then spat out graphs. That's how the best concert halls were done for the last 30-35 years.
Ircam did the "heavy lifting" on spatialisation, and modelling.
I haven't followed what came after, but from what I am aware, 3D modelling is now v advanced in France.