For Fs filter switching you need to look here. Camilla dont do that by itself. Its still unclear to me if Camilla can do it by using the rate adaption or/and resample option...
//
Yes, anything to anything, but it can't change its resampling ratio more than a few % without a reload.Yes - but there is also a Resample option in Camilla - will that resample anything to something, i.e. like a ASRC?
//
Nope, neither can do large changes on the fly. To accomodate a large change, it needs to resize its buffers, and regenerate the interpolation filters.Not Rate Adjust, nor Resample?
//
Any more ideas of the relationship between dB levels in Camilla & those actually seen at the transducer end?
To me it looks very much like dB/2or dB/2.5 to actual SPL conversion.
I go for a 9dB level change and I scarcely see 3dB at the "business
end".
That makes room/headphone correction seem more like guesswork.
To me it looks very much like dB/2or dB/2.5 to actual SPL conversion.
I go for a 9dB level change and I scarcely see 3dB at the "business
end".
That makes room/headphone correction seem more like guesswork.
Any more ideas of the relationship between dB levels in Camilla & those actually seen at the transducer end?
To me it looks very much like dB/2or dB/2.5 to actual SPL conversion.
I go for a 9dB level change and I scarcely see 3dB at the "business
end".
That makes room/headphone correction seem more like guesswork.
I think the REW measurement has too much smoothing. The applied peaks are quite narrow, and if you smooth the result too much the will shrink and get much wider. IIRC the default is to smooth quite a lot. Can you check that? I think you don't need to remeasure, just set a different smoothing for the display.
in REW (at least in the version I have now which has most of the 'orrible bugs missing), there are multiple struggles...
ie.
The microphones can't be identically placed each time.
In my case I found the 2 speakers (a pair) were vastly different from each other, despite Vandersteen's claims from anechoic chambers.
I found them so different I had to conclude there were defective components/out of spec in one of the crossovers.
You would't get this on BBC LS3/5. They went really mad to match pairs accurately over there in London.
So in short:-
levels from each microphone recording had to be carefully matched after the recording, and finally to get what seemed to be roughly the right levels after lots of tweaking we have to mess with offsets in the graphs because the speaker outputs comparing 2 pairs, for a given voltage input can be as much as 5-8dB different.
TBQH it's why I started with headphones.
At least I had a fairly accurate starting point, and there is no room acoustic/schroeder freq to mess with.
Additionally, the roll off on a mic, hardly works as expected on headphones, because you don't get the treble roll off when you have a strong proximity effect, and the lack of directional element (if any) changes the bass roll off also...
ie.
The microphones can't be identically placed each time.
In my case I found the 2 speakers (a pair) were vastly different from each other, despite Vandersteen's claims from anechoic chambers.
I found them so different I had to conclude there were defective components/out of spec in one of the crossovers.
You would't get this on BBC LS3/5. They went really mad to match pairs accurately over there in London.
So in short:-
levels from each microphone recording had to be carefully matched after the recording, and finally to get what seemed to be roughly the right levels after lots of tweaking we have to mess with offsets in the graphs because the speaker outputs comparing 2 pairs, for a given voltage input can be as much as 5-8dB different.
TBQH it's why I started with headphones.
At least I had a fairly accurate starting point, and there is no room acoustic/schroeder freq to mess with.
Additionally, the roll off on a mic, hardly works as expected on headphones, because you don't get the treble roll off when you have a strong proximity effect, and the lack of directional element (if any) changes the bass roll off also...
Projects like ASH-IR-Dataset provide a 2 channel impulse response as wav file.
Currently I splitting those files in two 1 channel files, but is there a way use those files directly with 2 channels.
For example can you select a channel from the FIR filter?
Currently I splitting those files in two 1 channel files, but is there a way use those files directly with 2 channels.
For example can you select a channel from the FIR filter?
This is currently not possible. It could of course be convenient sometimes, but working with raw files can be confusing so I prefer to keep the options as simple as possible.For example can you select a channel from the FIR filter?
Well, thanks to Henrik I could start camilladsp as a service, and at long last get the whole thing working beautifully.
Unfortunately a number of little things didn't work, or had to be started manually each time I rebooted the little Rpi (Arm SBC), despite Henrik's advice. (something inportant was missing so I try to describe it here).
This Rpi is running 64bit Raspi OS so this should help quite a few people.
I decided early on I wanted max flexibility so went with running VLC or CVLC using command lines, and then setting it all up using aloop as the source and the appropriate interface for output, which should be as follows....(to get you up with basic audio).
I chose "headphones" because that way I could get CamillaDSP to correct the defects of my old sennheisers automatically that I have been talking about for weeks, and it routes all the audio to the 3.5mm jack on the HDMI section
So here it is,-
pi@raspberrypi:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 7/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 1: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1]
Subdevices: 4/4
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
card 2: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
Subdevices: 3/4
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Unfortunately a number of little things didn't work, or had to be started manually each time I rebooted the little Rpi (Arm SBC), despite Henrik's advice. (something inportant was missing so I try to describe it here).
This Rpi is running 64bit Raspi OS so this should help quite a few people.
I decided early on I wanted max flexibility so went with running VLC or CVLC using command lines, and then setting it all up using aloop as the source and the appropriate interface for output, which should be as follows....(to get you up with basic audio).
I chose "headphones" because that way I could get CamillaDSP to correct the defects of my old sennheisers automatically that I have been talking about for weeks, and it routes all the audio to the 3.5mm jack on the HDMI section
So here it is,-
pi@raspberrypi:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
Subdevices: 7/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 1: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1]
Subdevices: 4/4
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
card 2: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
Subdevices: 3/4
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
I could then get camillaDSP to run as a service by copying the finished sources compiled binary to /usr/local/bin.
Next was making the camilladsp.service file in /etc/sytemd/system/ and updating via systemctl daemon-reload of course in this file we have to refer in Execstart to /usr/local/bin/camilladsp, then I told it to look for /home/pi/xxxx_rpi.yml as the dsp profile to use...
for some this may seem obvious but the service never started at reboot, which took a lot of head scratching..
I tried
systemctl enable camilladsp.service, which Henrik had forgotten.
still no luck...
systemctl status camilladsp always came up after reboot...
systemctl status camilladsp
* camilladsp.service - CamillaDSP Daemon
Loaded: loaded (/etc/systemd/system/camilladsp.service; enabled; vendor preset: enabled)
Active: inactive (dead)
I checked:- all seemed fine...but still nothing.
ls /etc/systemd/system/*.service
/etc/systemd/system/autologin@.service
/etc/systemd/system/camilladsp.service
/etc/systemd/system/dbus-fi.w1.wpa_supplicant1.service
/etc/systemd/system/dbus-org.bluez.service
/etc/systemd/system/dbus-org.freedesktop.Avahi.service
/etc/systemd/system/dbus-org.freedesktop.timesync1.service
/etc/systemd/system/dhcpcd5.service
/etc/systemd/system/display-manager.service
/etc/systemd/system/rtkit-daemon.service
/etc/systemd/system/sshd.service
/etc/systemd/system/syslog.service
ahum...
Finally I started to check and the "enable" command created a line under "graphical-target-wants"
This took quite a long while to sort ...but Ah!
Camilladsp is NOT A GRAPHIC TARGET!! Neither is VLC in command line!
So finally after copying the (by now 2 services-wants, the other being @vlc -I http, to give it a web interface etc, and @camillaDSP into the "multi-user.target.wants" it WORKS!!
In fact supplying the VLC program with a basic .m3u playlist by command line gets it started immediately playing a radio from boot, camilladsp boots with it, and hey presto ...you have a radio running perfectly just turning on your RPi (in this case it was a 3+).
The web interface pops up on any smartphone with a password to present to access it and you have volume controls AND can play any file on the microSD locally you care to mention...via the playlist menu...
A little extra comment
It was a similar situation with VLC so in the end I had to hack it with this vlcsudo sed -i 's/geteuid/getppid/' /usr/bin/vlc so that I could at least initialise it under sudo, or that also failed constantly in put cryptic comments in the syslog, saying you're not allowed to do that!
Hope this helps.
At no point have I had to use a mouse, keyboard or even a screen on the Rpi, all was done over SSH, even talking to the Gui over X11 export.
Next was making the camilladsp.service file in /etc/sytemd/system/ and updating via systemctl daemon-reload of course in this file we have to refer in Execstart to /usr/local/bin/camilladsp, then I told it to look for /home/pi/xxxx_rpi.yml as the dsp profile to use...
for some this may seem obvious but the service never started at reboot, which took a lot of head scratching..
I tried
systemctl enable camilladsp.service, which Henrik had forgotten.
still no luck...
systemctl status camilladsp always came up after reboot...
systemctl status camilladsp
* camilladsp.service - CamillaDSP Daemon
Loaded: loaded (/etc/systemd/system/camilladsp.service; enabled; vendor preset: enabled)
Active: inactive (dead)
I checked:- all seemed fine...but still nothing.
ls /etc/systemd/system/*.service
/etc/systemd/system/autologin@.service
/etc/systemd/system/camilladsp.service
/etc/systemd/system/dbus-fi.w1.wpa_supplicant1.service
/etc/systemd/system/dbus-org.bluez.service
/etc/systemd/system/dbus-org.freedesktop.Avahi.service
/etc/systemd/system/dbus-org.freedesktop.timesync1.service
/etc/systemd/system/dhcpcd5.service
/etc/systemd/system/display-manager.service
/etc/systemd/system/rtkit-daemon.service
/etc/systemd/system/sshd.service
/etc/systemd/system/syslog.service
ahum...
Finally I started to check and the "enable" command created a line under "graphical-target-wants"
This took quite a long while to sort ...but Ah!
Camilladsp is NOT A GRAPHIC TARGET!! Neither is VLC in command line!
So finally after copying the (by now 2 services-wants, the other being @vlc -I http, to give it a web interface etc, and @camillaDSP into the "multi-user.target.wants" it WORKS!!
In fact supplying the VLC program with a basic .m3u playlist by command line gets it started immediately playing a radio from boot, camilladsp boots with it, and hey presto ...you have a radio running perfectly just turning on your RPi (in this case it was a 3+).
The web interface pops up on any smartphone with a password to present to access it and you have volume controls AND can play any file on the microSD locally you care to mention...via the playlist menu...
A little extra comment
It was a similar situation with VLC so in the end I had to hack it with this vlcsudo sed -i 's/geteuid/getppid/' /usr/bin/vlc so that I could at least initialise it under sudo, or that also failed constantly in put cryptic comments in the syslog, saying you're not allowed to do that!
Hope this helps.
At no point have I had to use a mouse, keyboard or even a screen on the Rpi, all was done over SSH, even talking to the Gui over X11 export.
I discovered a bug:
In a config file set a pair of destination channels in the mixer to mute: false and then start camilladsp. It will output sound as expected. However, if you then set mute: true and reload the config using pycamilladsp, it won't mute the channels. It will however work as expected if you stop camilladsp and restart it. The log below is from after the config reload.
In a config file set a pair of destination channels in the mixer to mute: false and then start camilladsp. It will output sound as expected. However, if you then set mute: true and reload the config using pycamilladsp, it won't mute the channels. It will however work as expected if you stop camilladsp and restart it. The log below is from after the config reload.
Code:
Feb 21 20:04:41.811 DEBG Reloading configuration..., module: camilladsp
Feb 21 20:04:41.811 DEBG Reload using config from websocket, module: camilladsp
Feb 21 20:04:41.814 DEBG Config valid, module: camilladsp
Feb 21 20:04:41.814 DEBG Using channels [true, true], module: camilladsp
Feb 21 20:04:41.814 DEBG Sent changes to pipeline, module: camilladsp
I fixed a bug. At least I think so. Could you try the current develop branch?I discovered a bug:
Confirmed, the bug has been squashed. Thanks!I fixed a bug. At least I think so. Could you try the current develop branch?
I have some further questions as to the reference levels used in the .yml files and the actual SPL produced at the transducer end, and the abrupt phase changes caused by IR filters.
This appears to be relative to "energy values", rather than electrical signal levels. The relative energy levels to be tamed at LF are enormous compared with HF, so it appears to use a non linear transform.
I have struggled a lot to understand how to get this to work in the real world, because microphones don't suffer from the same "phons" curve sensitivity as do the human ear.
(they simply roll off the LF, or distort it). It's at this point the human ear is no help, because of the relative insensity at LF, and relative tolerance of high distortion levels....
eg.
I used a "q" of 6.2 and a dip of -9.9 to tame a combined driver resonance at 135hz, because all attempts around -3 to -5dB had little effect.
(which as luck would have it was only on ONE channel).
That as you can see on the graph eliminated it..but about -8dB out compared to nr -10dB on camilla, followed by a sharp dip due to the phase reversal caused by the IR filter.
I am well aware the "Q" value is related to 2sq/rt so that 1.414 = 1 octave. In this respect 1 octave at LF is a very different affair from 1 octave at HF.
In effect it means a "Q" of 2.8 is 1/2 octave and so forth.
The problematic becomes more difficult as you head north to the HF stratosphere, because as the energy content is much lower, it makes for a different transform, and then you have to work in 1/4-1/12 octave steps or even smaller, which means very high "Q" values.
I can see Camilla works because I made a mistake trying to remove a horn tweeter resonance at what I thought was just below 5.9khz..as you can see.
There is some satisfaction I suppose to see JBL also have the same problem, with a sharp dip as their crossover takes over from the large horn to the Ti based tweeter.
In fact I was suprised to see how well their horn driver behaves.
Something much more funny, the JBL pair are a close match, whereas the much vaunted Vandersteen 3 ("we set each one perfectly in an anechoic chamber") is all over the place to the extent I suspect defects in components...and terrible quality control.
My microphones showed me clearly from REW, the resonance wasn't there at all in my own horn tweeter. (-4db 5650hz "Q" 3.9), it was clearly some 900hz higher at 6.5khz...oops! You can see it on the graph.
However at this HF range the camilla notch of -4dB results in an actual -7dB notch, plus an abrupt +/-30 deg phase reversal, which add to the interesting effects using a simple first order crossover.
Another point.
Nothing beats real world testing, then a rule of thumb method to add the corrections to Camilla biquad, bit by bit to flatten the peaks and then correct the corrections,
because they have a giant effect on phase also.
Any comments?
This appears to be relative to "energy values", rather than electrical signal levels. The relative energy levels to be tamed at LF are enormous compared with HF, so it appears to use a non linear transform.
I have struggled a lot to understand how to get this to work in the real world, because microphones don't suffer from the same "phons" curve sensitivity as do the human ear.
(they simply roll off the LF, or distort it). It's at this point the human ear is no help, because of the relative insensity at LF, and relative tolerance of high distortion levels....
eg.
I used a "q" of 6.2 and a dip of -9.9 to tame a combined driver resonance at 135hz, because all attempts around -3 to -5dB had little effect.
(which as luck would have it was only on ONE channel).
That as you can see on the graph eliminated it..but about -8dB out compared to nr -10dB on camilla, followed by a sharp dip due to the phase reversal caused by the IR filter.
I am well aware the "Q" value is related to 2sq/rt so that 1.414 = 1 octave. In this respect 1 octave at LF is a very different affair from 1 octave at HF.
In effect it means a "Q" of 2.8 is 1/2 octave and so forth.
The problematic becomes more difficult as you head north to the HF stratosphere, because as the energy content is much lower, it makes for a different transform, and then you have to work in 1/4-1/12 octave steps or even smaller, which means very high "Q" values.
I can see Camilla works because I made a mistake trying to remove a horn tweeter resonance at what I thought was just below 5.9khz..as you can see.
There is some satisfaction I suppose to see JBL also have the same problem, with a sharp dip as their crossover takes over from the large horn to the Ti based tweeter.
In fact I was suprised to see how well their horn driver behaves.
Something much more funny, the JBL pair are a close match, whereas the much vaunted Vandersteen 3 ("we set each one perfectly in an anechoic chamber") is all over the place to the extent I suspect defects in components...and terrible quality control.
My microphones showed me clearly from REW, the resonance wasn't there at all in my own horn tweeter. (-4db 5650hz "Q" 3.9), it was clearly some 900hz higher at 6.5khz...oops! You can see it on the graph.
However at this HF range the camilla notch of -4dB results in an actual -7dB notch, plus an abrupt +/-30 deg phase reversal, which add to the interesting effects using a simple first order crossover.
Another point.
Nothing beats real world testing, then a rule of thumb method to add the corrections to Camilla biquad, bit by bit to flatten the peaks and then correct the corrections,
Any comments?
Attachments
Last edited:
Trying to work this out through the mess of a speaker with it's peaks and dips plus another set of dips and peaks from the room will be very difficult. Can you try measuring directly on the analog output, without any speaker or power amplifier in the path?
Also the curves in REW look too smooth. I think there is still some smoothing applied. Can you turn that off? Click the "All SPL" button at the top, then select "Controls" and in there select no smoothing and apply. No need to remeasure for that.
![rew.jpg rew.jpg](https://www.diyaudio.com/community/data/attachments/848/848070-36a3d333c064d113e2eba5882d9a3099.jpg)
Also the curves in REW look too smooth. I think there is still some smoothing applied. Can you turn that off? Click the "All SPL" button at the top, then select "Controls" and in there select no smoothing and apply. No need to remeasure for that.
![rew.jpg rew.jpg](https://www.diyaudio.com/community/data/attachments/848/848070-36a3d333c064d113e2eba5882d9a3099.jpg)
That's exactly what I do.Can you try measuring directly on the analog output,
I wasn't v clear about the methodology I use.
In order to test the linearity of any system I always use a loopback test. The stereo (studio quality) sound card has one of the outputs slotted into the input (XLR connectors). It works as expected, and can be calibrated to whatever level we like (below clip).
The 20-20khz scan at 0dB level is generated by the software, and the levels measured.
The spdif output of the card was fed into the DAC of my friend's system then.
We also measure the analog output of that and record the results. (It was a sabre DAC). Mine uses a AKM.
Usually a 1khz square wave test is enough to divide the sheep from the goats, and this was no exception.
The Cayin (sabre) DAC was unstable with the output giving a 0.5-1hz constant phase change, and lots of jitter. The AKM nothing.
I could test it then at 20hz, 400hz and 6khz, to find the phase jitter was unequal over the entire band.
The AKM DAC had a slight fall off of response at about 18-20khz. Nothing bad, max of about 1-1.5dB.
We then go and run the same kind of tests thru the amp, channel by channel first with resistive loads, at up to full power (no 1W test for me!), this is done by using a little extension cable from a dummy load, and the same for the back of the speaker to test the difference for a real inductive load.
So as not to blow up the sound card a 100k/10k resistor voltage divider drops the level back to roughly the level the sound card supports, and the result can be recorded as well as displayed in real time via a program called "scope", a v nice oscilloscope.
(In our case the transistor amp demonstrated a sharp drop off of about -5dB from 18-20khz, whereas one of the valve amps showed a rise from 15-20khz of about 2dB).
We then place Neumann or DPA mics 1m from the front of the speakers and record each one.
The results are compared with the source and playback from the amp.
The recording with all the peaks and troughs are shown first on the audio recording program, and can be checked here and there for level.
It's extremely obvious in the blink of an eye where the peaks and troughs in response are, as one channel (typically the LEFT) shows the playback, while the RH shows the Loopback.
(that's as you say the raw output)
You can then compare both the amp voltage output with the loopback and check them all for distortion of wave forms.
Click the "All SPL" button at the top, then select "Controls" and in there select no smoothing and apply.
well if you do that, you get so much gobbledeegook, you get lost in a mountain range.
Using a 1/12 smoothing, at least makes the graphs readable.
The tests were extremely rigorous and objective, which if carried out in a very heavily damped room (the ones above were), have absolutely minimal room reflections.
The only reservation I have is the heavy roll off of the bass with the Neumann mics (below100hz), which in fact make the speakers look much better than they really are, when they produce a boom at say 50hz.
Being as we use the same mic for all the tests, it doesn't actually really affect the results.
The Neumann (nice KM series) also has a small peak from about 14khz on, which frankly doesn't bother me either.
I have the graphs from Neumann, and they are completely correct.
I have no doubt, listening to the sound files playback on headphones (which I have now corrected with Camilla,of course..) they are a very good reflection of reality.
Once pointed out to the owner of the amp and speakers, did observe in fact we had shown the defects in the speakers, which he literally did not know existed.
What was even more suprising was to see how BAD & inconsistent the Vandersteens were compared with the JBLs, (which were essentially the same speakers as a pair).
This to my mind with the strong dips in the 100-250hz range is why the Vandersteen is nigh on useless for certain types of music.
I tried to correct to for this with Camilla,and it immediately made them sound brighter and better...
In our back to back test of the JBL (basically a studio type monitor), against the pair of Vandersteen 3, we were trying to find out, why the VAND speakers sounded basically crap in rock music, but good for classical/Jazz, while the JBLs were completely the reverse.
The whole lot was a winter time experiment, which sought to find out why certain amp and speaker combos don't work, or sound harsh, particularly on digi compressed music, and others sounded simply magical.
In this experiment we tried to find out if there was a typical "valve sound", and if the transistor amp sounded drier or cleaner or whatever.
To be able to switch in a DSP such as camilla and program the different notches and filters as it were "on the fly", added an extra element, so that we try to get one valve amp to sound like the the solid state one...
We are still working on that, but one amp in particular came out outstandingly good, noticeably better sounding than the other 2 (a valve amp & the solid state one)
(It was my own design valve amp which has just started to be produced, and turns out to have a truly magical sound...but that's another story).
why is this so relevant to Camilla?
Because it's the first time I'm using Linux to deal with pro sound, & the Raspberry pi4 looks like it's going to be a far better solution with far less phase wobbling & jitter than anything I have seen so far from these so called "hi end" DACs that perform so badly.
Sorry this is so long, but it gives a certain relevancy to the whole program, and what is possible to do with it. (if you want).
If you think that I apologise.
I was actually pointing out an issue, where with camilla what you see is not what you get.
This may be common to many DSP, but when applied to an end-end acoustic system and used to make a valve amp sound like a solid state amp it's getting interesting for a lot of people.
Correcting what are supposed to be "hi end" speakers (which btw were a friend's system not mine....), and then show him where they don't work and why....
This is all very new, and a completely "modular approach" very DIY!
I think this is especially true with an all new SBC which has literally been out no more than 2 months, (is currently difficult to get, cos they are sold out...) a new 64 bit Linux kernel barely a month now, the dual DAC hat just about available...and Hendrik's last release really since the end of last year.
If you want to go boldly where none have been before this is it!
Hendrik gave me a lot of help to sort out a number of issues, because that's exactly the point.
It's all about application, then finding out what can be improved.
I was actually pointing out an issue, where with camilla what you see is not what you get.
This may be common to many DSP, but when applied to an end-end acoustic system and used to make a valve amp sound like a solid state amp it's getting interesting for a lot of people.
Correcting what are supposed to be "hi end" speakers (which btw were a friend's system not mine....), and then show him where they don't work and why....
This is all very new, and a completely "modular approach" very DIY!
I think this is especially true with an all new SBC which has literally been out no more than 2 months, (is currently difficult to get, cos they are sold out...) a new 64 bit Linux kernel barely a month now, the dual DAC hat just about available...and Hendrik's last release really since the end of last year.
If you want to go boldly where none have been before this is it!
Hendrik gave me a lot of help to sort out a number of issues, because that's exactly the point.
It's all about application, then finding out what can be improved.
Last edited:
- Home
- Source & Line
- PC Based
- CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.