There's nothing quite like finding people in denial...
TBH I wasn't so much interested in the speakers to begin with so did a blind test on my own children with my SENNs, which they use on a daily basis on their smartphones & who can hear well up to 22khz+ (cos they are young girls).
The blind test showed they got 100% success rate in their answers ie. which were the headphones with DSP correction and without.
They found the DSP version was so brilliant they didn't want to take them off.
As soon as I put on some more aggressive music without DSP they ran off and refused to put them back on.
To me that's convincing enough to rest my case.
Running the same ancient SENNs for a number of hours, and getting used to the delightful 21st century sound, makes it possible to make a number of important observations.
Remember these were standard issue for BBC engineers for nr 2 decades, so that "sound" formed their "education" and broadcast world.
1/ when you switch back to the "OEM" version it's obvious how harsh it is.
2/ when you compare the 2, (a .yml file "flat" and another one "treated") it's obvious without DSP the headphones have clear evidence of resonant ringing**. It's this constant ringing that introduces heavy distortion in the LF region.
3/ the OEM headphones (BBC HD414) clearly have dynamic range limitations because of the ringing causing the distortion.
When running the DSP driven version the distortion level then drops thru the floor, giving up to 20dB larger dynamic range - that's simply an incredible result.
We have to thank linkwitz** for having tested these headphones decades ago, so that we could get a genuine test.
following his graphs enabled me to make an extremely accurate correction, which is more difficult with other headphones using the "neumann method" - specialised dummy head etc..
TBH I wasn't so much interested in the speakers to begin with so did a blind test on my own children with my SENNs, which they use on a daily basis on their smartphones & who can hear well up to 22khz+ (cos they are young girls).
The blind test showed they got 100% success rate in their answers ie. which were the headphones with DSP correction and without.
They found the DSP version was so brilliant they didn't want to take them off.
As soon as I put on some more aggressive music without DSP they ran off and refused to put them back on.
To me that's convincing enough to rest my case.
Running the same ancient SENNs for a number of hours, and getting used to the delightful 21st century sound, makes it possible to make a number of important observations.
Remember these were standard issue for BBC engineers for nr 2 decades, so that "sound" formed their "education" and broadcast world.
1/ when you switch back to the "OEM" version it's obvious how harsh it is.
2/ when you compare the 2, (a .yml file "flat" and another one "treated") it's obvious without DSP the headphones have clear evidence of resonant ringing**. It's this constant ringing that introduces heavy distortion in the LF region.
3/ the OEM headphones (BBC HD414) clearly have dynamic range limitations because of the ringing causing the distortion.
When running the DSP driven version the distortion level then drops thru the floor, giving up to 20dB larger dynamic range - that's simply an incredible result.
We have to thank linkwitz** for having tested these headphones decades ago, so that we could get a genuine test.
following his graphs enabled me to make an extremely accurate correction, which is more difficult with other headphones using the "neumann method" - specialised dummy head etc..
YES.
I went to the trouble of swapping different speakers on the fly.
As it's a shop, it was easy to grab the wires from the amp and plug them into 2 other pairs of monitors.
(I forget the makes now).
We all preferred the W'dale in fact, a suprise and an excellent all rounder.
The worst (which I had done without the benefit of hindsight, and without DSP) had a speaker resonance at roughly the same as that of the room.
. That was from Finnish firm Amphion.The resonance of both together was impressive, which makes any attempt at objectivity,- checking and testing amplifiers when even the speakers are basically at 4ohms instead of 8...well, let say..
'nuff said!
A pair of Vandersteens, clearly were more neutral in my old tests, in the "bad room", at the same time as we tested the amphions, and confirmed they didn't like certain types of music.
When we tested a pair in a "fairly dead room" it again showed clearly how unsuitable they were for loud rock or heavy metal music...as well as how obvious the differences of sound became swopping between 3 different amps and bi or single wiring...
It proved a lot of things.
A/ You can't really buy speakers from "hi end audio" shops, because usually a combo of an awful auditorium, or awful amp/speaker matches would show up.
B/ Some of the most expensive amps and speakers were really "toilet". The staff preferred to sell the "expensive cables", "burn in", and "magic pixie" stuff while being ignorant of the most basic electronic science, inc basics such as being able to run 2 sets of speakers, or bi wired bass and treble off most valve amps, because they have multi taps on the OPT.
C/ In some cases those same "hi end" amps when presented with loads other than "ideal" could do quite horrible things.
Some of them proceed to melt stuff quite quickly if given a proper work out. (ouch!)
NB:-
I test my own into both inductive and resistive loads, and trace the waveforms, mostly close to full power, which it has to maintain without blowing up for 30 mins ON BOTH channels loaded.
On my own home studio system, camilla DSP successfully cured a nasty 6khz resonance in an old Lomo driver (a clear copy of the famous Altec 288B etc), which made my Russian friends always say was a poor sounding driver, and had rejected it for those reasons.
Once that resonance & ringing was gone, the sound is pure magic, much better than his modern JBLs which are basically "honky" or "shouty".
I run square, triangular and sine tests across the entire band from 20hz - 28khz, including into genuine speaker drivers, (The compression horn drivers are still showing really good output at 25khz, as shown by professional mics such as B & K, but it must drive the neighbours cats crazy).
Hope this wasn't too long.
I tried the delay now and don't see any problem.
I used a mono signal with a single spike, and used a mixer to get 4 channels. Then I left one channel untouched, and delayed the others with 3.80, 3.82 and 3.84 ms.
All three delayed channels end up where they should:
Zooming in:
This was done at 44.1kHz, so the steps of 0.02 ms corresponds to a about one sample. The spike is delayed as expected.
Next marathon is arriving this weekend.
Vandersteen, nice crossover mess.
I checked and YES this is where the crossover is.
We will have a play with camilla again for this one.
This is how the monobloc amps behave...
Now that is a case for analogue components.
The bottom trace is my own design amp, which is as flat as a biliard table.
Vandersteen, nice crossover mess.
I checked and YES this is where the crossover is.
We will have a play with camilla again for this one.
This is how the monobloc amps behave...
Now that is a case for analogue components.
The bottom trace is my own design amp, which is as flat as a biliard table.
Well OK, thanks for the bit about attaching images.
I don't do things quite the classic (amateur) way, so my DAW records the system scan 20-20khz via studio mics such as DPA, or in my case Neumann KM series, (not an "impulse" response at all).
Some people like doing "old school" which works equally well and doesn't need a computer at all.
[In pro hall acoustic scenarii, my Prof friend used to use bursting balloons on concert hall stages for impulse, use a pro HP calibrated SPL microphone - which costs a lot, then put it through his old HP pocket device, which spat out .csv files dead easy, - all a real smart idea).
Many people may not be aware because of night club and pub venues having noise limits, we have been doing this sort of work for some decades now.
DPA mics have much higher output, so setting 0dB level can be a tad complex editing the final complete .wav files.
However, of course REW is quite capable of displaying the entire FR scan,- which I just realised only this week.
This shows up peaks and troughs like a dream, inc the same when recording a trace of a load resistor on the end of the amp, -
then a voltage trace off the speaker terminals using program "scope" works very well with a voltage divider network (ie. a couple of 10k + 90k/100k resistors works perfectly for that to spit the attnuated signal direct back into the pro sound card....),
And then finally you can measure the last one - what you get back off the DPA mics compared with the signal output from the DAW to get comparisons from A-Z.
Once you put the corrected signal from camilla back through the DAC, that peak on the vandersteen (1.3-2khz) can be erased, -
but the peak out of the amp on the RHS (150-190hz) I would prefer to knock out with a plain ordinary band stop RC filter and a little switch on the rear panel.
Horses for course and all that...
I'm not sure you follow quite all my methodology but it works rather well.
I don't do things quite the classic (amateur) way, so my DAW records the system scan 20-20khz via studio mics such as DPA, or in my case Neumann KM series, (not an "impulse" response at all).
Some people like doing "old school" which works equally well and doesn't need a computer at all.
[In pro hall acoustic scenarii, my Prof friend used to use bursting balloons on concert hall stages for impulse, use a pro HP calibrated SPL microphone - which costs a lot, then put it through his old HP pocket device, which spat out .csv files dead easy, - all a real smart idea).
Many people may not be aware because of night club and pub venues having noise limits, we have been doing this sort of work for some decades now.
DPA mics have much higher output, so setting 0dB level can be a tad complex editing the final complete .wav files.
However, of course REW is quite capable of displaying the entire FR scan,- which I just realised only this week.
This shows up peaks and troughs like a dream, inc the same when recording a trace of a load resistor on the end of the amp, -
then a voltage trace off the speaker terminals using program "scope" works very well with a voltage divider network (ie. a couple of 10k + 90k/100k resistors works perfectly for that to spit the attnuated signal direct back into the pro sound card....),
And then finally you can measure the last one - what you get back off the DPA mics compared with the signal output from the DAW to get comparisons from A-Z.
Once you put the corrected signal from camilla back through the DAC, that peak on the vandersteen (1.3-2khz) can be erased, -
but the peak out of the amp on the RHS (150-190hz) I would prefer to knock out with a plain ordinary band stop RC filter and a little switch on the rear panel.
Horses for course and all that...
I'm not sure you follow quite all my methodology but it works rather well.
In effect the amp peak problem should be doable as follows..
will take a bit of fiddling around with values no doubt.
One of the fascinating dealing with valve amps, especially vintage ones, is the interesting way they interact with both bi wiring and variable speaker driver impedances.
I have signal traces which really do show such things happening. The load presented (inductive v capacitive) really does have an effect on the sound.
Directly coupled devices running in the A2/AB2 condition have a very different behaviour from what most people are used to, and they certainly don't sound anything like solid state ones. (we tried).
The transformers are 70yrs old, and I am reluctant to change them, as it's highly possible they are only to blame for the HF roll off.
After extensive audition recently, we became aware of a certain "harshness" I could not explain neither from extensive measurements which included THD & IMD tests, and tests at certain power levels with certain speakers & certain codecs such as mp4 (H264) & particularly the horns in JBL. (which we will soon see analyse and verify tomorrow).
Before going mad with Camilla which brings its own crop of massive phase shifts...I wanted to "do it my own way".
Sherlock Holmes situation, "elementary my dear Watson" merely a process of elimination.
Excuse the circuit details which some may not be familiar here. it's quite "old school".
will take a bit of fiddling around with values no doubt.
One of the fascinating dealing with valve amps, especially vintage ones, is the interesting way they interact with both bi wiring and variable speaker driver impedances.
I have signal traces which really do show such things happening. The load presented (inductive v capacitive) really does have an effect on the sound.
Directly coupled devices running in the A2/AB2 condition have a very different behaviour from what most people are used to, and they certainly don't sound anything like solid state ones. (we tried).
The transformers are 70yrs old, and I am reluctant to change them, as it's highly possible they are only to blame for the HF roll off.
After extensive audition recently, we became aware of a certain "harshness" I could not explain neither from extensive measurements which included THD & IMD tests, and tests at certain power levels with certain speakers & certain codecs such as mp4 (H264) & particularly the horns in JBL. (which we will soon see analyse and verify tomorrow).
Before going mad with Camilla which brings its own crop of massive phase shifts...I wanted to "do it my own way".
Sherlock Holmes situation, "elementary my dear Watson" merely a process of elimination.
Excuse the circuit details which some may not be familiar here. it's quite "old school".
Attachments
I changed this now so it only logs a warning when an underrun starts, and then an info message when playback continues. Dropped callbacks in between aren't logged. It's in the develop branch. Could you try to see if it behaves properly in your system?Thanks, I'm already compiling the code myself anyways. I just figured that I might not be the only one having the desire to dial it down a bit, since it obscures relevant debug and trace information. Not receiving any sample rates when playback is stopped is after all perfectly normal behaviour and hardly justifies logging at Warning level, IMHO of course
Sure! I just recompiled it. When I run camilladsp without an existing active audiostream, I get the following:
Code:
Feb 14 20:17:29.017 DEBG build filters, waiting to start processing loop, module: camillalib::processing
Feb 14 20:17:29.031 DEBG Opened CPAL playback device Digiface USB (24011413), module: camillalib::cpaldevice
Feb 14 20:17:29.031 DEBG Opened CPAL capture device Digiface USB (24011413), module: camillalib::cpaldevice
Feb 14 20:17:29.031 DEBG Playback thread ready to start, module: camilladsp
Feb 14 20:17:29.031 DEBG Capture thread ready to start, module: camilladsp
Feb 14 20:17:29.031 DEBG Both capture and playback ready, release barrier, module: camilladsp
Feb 14 20:17:29.031 TRCE Build f32 input stream, module: camillalib::cpaldevice
Feb 14 20:17:29.031 TRCE Build f32 output stream, module: camillalib::cpaldevice
Feb 14 20:17:29.665 TRCE f32 output stream ready, module: camillalib::cpaldevice
Feb 14 20:17:29.671 WARN Playback interrupted, no data available, module: camillalib::cpaldevice
Feb 14 20:17:29.678 TRCE f32 input stream ready, module: camillalib::cpaldevice
Feb 14 20:17:29.678 DEBG Starting capture loop, module: camillalib::cpaldevice
Feb 14 20:17:29.678 DEBG Starting playback loop, module: camillalib::cpaldevice
Feb 14 20:17:29.691 INFO Restarting playback after buffer underrun, module: camillalib::cpaldevice
Feb 14 20:17:30.576 WARN Playback interrupted, no data available, module: camillalib::cpaldevice
Feb 14 20:17:30.582 INFO Restarting playback after buffer underrun, module: camillalib::cpaldevice
Feb 14 20:17:30.624 WARN Playback interrupted, no data available, module: camillalib::cpaldevice
Code:
Feb 14 20:20:47.943 TRCE Measured sample rate is 216.9173087706881 Hz, module: camillalib::cpaldevice
Feb 14 20:20:47.945 DEBG Current buffer level: 64.66666666666667, corrected capture rate: 100.025%, module: camillalib::audiodevice
Feb 14 20:20:47.945 DEBG Current buffer level 64.66666666666667, set capture rate to 100.025%, module: camillalib::cpaldevice
Feb 14 20:20:47.945 DEBG SetSpeed message received, module: camilladsp
Feb 14 20:20:47.946 INFO Restarting playback after buffer underrun, module: camillalib::cpaldevice
Feb 14 20:20:48.946 TRCE Measured sample rate is 191961.14350357355 Hz, module: camillalib::cpaldevice
Feb 14 20:20:49.949 TRCE Measured sample rate is 192013.1180451411 Hz, module: camillalib::cpaldevice
Feb 14 20:20:50.952 TRCE Measured sample rate is 191992.86741391366 Hz, module: camillalib::cpaldevice
Feb 14 20:20:51.954 TRCE Measured sample rate is 191988.0806548916 Hz, module: camillalib::cpaldevice
Feb 14 20:20:52.957 TRCE Measured sample rate is 191996.9761752828 Hz, module: camillalib::cpaldevice
Feb 14 20:20:53.960 TRCE Measured sample rate is 191993.71297183252 Hz, module: camillalib::cpaldevice
Feb 14 20:20:54.962 TRCE Measured sample rate is 191991.2877570491 Hz, module: camillalib::cpaldevice
Feb 14 20:20:55.965 TRCE Measured sample rate is 191992.30888257048 Hz, module: camillalib::cpaldevice
Feb 14 20:20:56.968 TRCE Measured sample rate is 191986.93186824262 Hz, module: camillalib::cpaldevice
Feb 14 20:20:57.945 DEBG Current buffer level: 12, corrected capture rate: 100.02635416666668%, module: camillalib::audiodevice
Feb 14 20:20:57.945 DEBG Current buffer level 12, set capture rate to 100.02635416666668%, module: camillalib::cpaldevice
Feb 14 20:20:57.945 DEBG SetSpeed message received, module: camilladsp
Feb 14 20:20:57.970 TRCE Measured sample rate is 191996.3777917409 Hz, module: camillalib::cpaldevice
Code:
Feb 14 20:22:41.247 TRCE Measured sample rate is 191993.7369064382 Hz, module: camillalib::cpaldevice
Feb 14 20:22:42.251 TRCE Measured sample rate is 185584.22381780826 Hz, module: camillalib::cpaldevice
Feb 14 20:22:43.305 TRCE Measured sample rate is 60259.1443325083 Hz, module: camillalib::cpaldevice
Feb 14 20:22:43.351 WARN Playback interrupted, no data available, module: camillalib::cpaldeviceRight, the marathon is over.... This should be a lot of interest to those using the DSP.
I did 2 tests all over again, using Neumann microphones as my basis, on both speakers and headphones.
It seems my old version of REW spat out garbage instead of correctly analysing scan traces and making them into clear graphs. I had to get a newer version, then work from there...(as the stuff I posted here before turned out to be largely invalid huh!)
Now, as Camilla is now spitting out lots of nice graphs thanks to python, I thought it sensible to give some feedback from the results.
Unfortunatlely it's more complicated than that, which involves a lot of inspired guess work and listening carefully to the results...
Basically what you see, and what you program into the .yml file is not what comes out of your transducers.
That is the tough part.
To help me in this I continued to play with my old Sennheiser HD units to see what I could do to improve on what Linkwitz had done. (It's a lot easier than fooling with large rooms and reflections!)
From what I see linkwitz idea was successful supressing resonances up at 8 & 12khz, which were causing the capsules to produce nasty artefacts lower down.
I did what you are never supposed to do, and put the mics direct into the headphones to measure what was actually coming out.
It turns out there was an extra really nasty peak at 5khz.
Ignoring Harman seems to be the best method here!
So what I get from Camilla trace looks like this:-
While what I get back from my measurements direct from the SENNS with 10s, 20hz-20khz scans from mic recording direct then stuffed into REW looks like this..
The top trace is with NO DSP, the bottom using the DSP trace above.
Not the notch at 8400...that helps get a handle on the (rather cryptic) relationship between the 2.
The 7dB stab we get at with camilla gives me only 2-3dB real..see?
Obviously when it comes to doing speakers and comparing them it becomes a good deal more complex.
That at least enabled me to get a trace on 2 ostensibly identical Vandersteen speakers which were not identical at all....
I did 2 tests all over again, using Neumann microphones as my basis, on both speakers and headphones.
It seems my old version of REW spat out garbage instead of correctly analysing scan traces and making them into clear graphs. I had to get a newer version, then work from there...(as the stuff I posted here before turned out to be largely invalid huh!)
Now, as Camilla is now spitting out lots of nice graphs thanks to python, I thought it sensible to give some feedback from the results.
Unfortunatlely it's more complicated than that, which involves a lot of inspired guess work and listening carefully to the results...
Basically what you see, and what you program into the .yml file is not what comes out of your transducers.
That is the tough part.
To help me in this I continued to play with my old Sennheiser HD units to see what I could do to improve on what Linkwitz had done. (It's a lot easier than fooling with large rooms and reflections!)
From what I see linkwitz idea was successful supressing resonances up at 8 & 12khz, which were causing the capsules to produce nasty artefacts lower down.
I did what you are never supposed to do, and put the mics direct into the headphones to measure what was actually coming out.
It turns out there was an extra really nasty peak at 5khz.
Ignoring Harman seems to be the best method here!
So what I get from Camilla trace looks like this:-
While what I get back from my measurements direct from the SENNS with 10s, 20hz-20khz scans from mic recording direct then stuffed into REW looks like this..
The top trace is with NO DSP, the bottom using the DSP trace above.
Not the notch at 8400...that helps get a handle on the (rather cryptic) relationship between the 2.
The 7dB stab we get at with camilla gives me only 2-3dB real..see?
Obviously when it comes to doing speakers and comparing them it becomes a good deal more complex.
That at least enabled me to get a trace on 2 ostensibly identical Vandersteen speakers which were not identical at all....
Attachments
Last edited:
I'm somewhat new to this whole thing, and I have a question that maybe others with more software experience could help answer. It's related to what Darkless found before:
I would like to create a setup with CamillaDSP on a Raspberry Pi and something like the MiniDSP USBStreamer to do fully-digital DSP processing for 2-channel audio. The idea would be to use it as an open-source room-correction DSP solution that doesn't involve any unnecessary A/D or D/A and has (potentially a ton) more processing power than one of the SHARC or MCU based solutions.
I have re-introduced myself to Alsa and gotten a basic CamillaDSP setup running on a Pi I had lying around with an E-MU 0404 USB (analog in/out for now). Before I go off and drop money on the USBStreamer, I'd like to know if the sample rate switching is going to be an issue? Ideally, I'd like the [SPDIF In] --> [Pi CamillaDSP] --> [SPDIF Out] to be able to support all possible sample rates from 44100 to 192000, automatically. I know this would potentially require different FIR configs, but I'm wondering if this sounds possible? Are there things I'm overlooking that would make this project excessively difficult?
If not, I'm thinking this is a pretty nice solution for room DSP that has the potential to be much more powerful than the current offerings, running on relatively inexpensive hardware. In the future, with something like the UMIK-1 and some type of display, it could become fully self-contained [REW] --> [RePhase(Wine)] --> [CamillaDSP] system.
I would like to create a setup with CamillaDSP on a Raspberry Pi and something like the MiniDSP USBStreamer to do fully-digital DSP processing for 2-channel audio. The idea would be to use it as an open-source room-correction DSP solution that doesn't involve any unnecessary A/D or D/A and has (potentially a ton) more processing power than one of the SHARC or MCU based solutions.
I have re-introduced myself to Alsa and gotten a basic CamillaDSP setup running on a Pi I had lying around with an E-MU 0404 USB (analog in/out for now). Before I go off and drop money on the USBStreamer, I'd like to know if the sample rate switching is going to be an issue? Ideally, I'd like the [SPDIF In] --> [Pi CamillaDSP] --> [SPDIF Out] to be able to support all possible sample rates from 44100 to 192000, automatically. I know this would potentially require different FIR configs, but I'm wondering if this sounds possible? Are there things I'm overlooking that would make this project excessively difficult?
If not, I'm thinking this is a pretty nice solution for room DSP that has the potential to be much more powerful than the current offerings, running on relatively inexpensive hardware. In the future, with something like the UMIK-1 and some type of display, it could become fully self-contained [REW] --> [RePhase(Wine)] --> [CamillaDSP] system.
This is doable, but how to do it depends on the hardware you use. Every device seems to handle SPDIF differently. When using SPDIF input there are a few cases that must be handled, when the signal:
- changes sample rate without interruption
- stops and then comes back at the same rate
- stops and then comes back at a different rate
Not so many, the problem is that every device behaves differently.
Some devices have a built in ASRC (for example miniDSP UDIO-8) so whatever happens they continue delivering data at the rate you requested. Others (most is seems) simply deliver the data that comes in. Setting the capture sample rate of these doesn't actually do anything. If the rate changes, they simply deliver data at the new rate instead (while still officially running at the configured rate).
Another group does basically the same, but has driver quirks (Hifiberry digiIO and probably others) so the capture stops with an error. Then the capture device must be closed and reopened to continue.
Trying to handle all of these inside CamillaDSP would become a complete mess. Instead it need something to tell it what to do. For example a python script watching the status of things, and restarting CamillaDSP with a new config when needed.
I don't know what the USBstreamer will do. I think the only way to know is to try it, or find someone who already did.