CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.

Based on your log it looks like your capture device doesn’t like the S32LE format, I think you want this to be S16LE.

Don’t quite understand the GUI issues to be honest. Do you have this configuration saved to camilladsp.yml? Just wondering if your camilladsp is starting with a different configuration that works but when you load your USB input configuration it doesn’t work because of the S32LE vs S16LE issue?

Michael
 
That seemed to have worked but tried to load the squeezelite config and it didn't seem to pick it up after applying to the dsp. Doing a fetch just got the old config back again.

I think I will build another SDCARD from scratch, it did seem to work for a while at least. I will keep th card that has the SW causing me the issue as is so i can try out any other ideas people may have.
 
The rebuilt Ubuntu/Camilla is working fine so far. Must admit I went for v0.6.3 just to be safe, may go to a more recent version at a later date if all goes well.
At this point I am wondering if all the config changes, saving, loading confused things causing the issues I had. Certainly confused me:unsure:

Anyhow thanks for the help, hopefully I won't be asking more questions for a while.
 
Last edited:
I got some syntax error. Can you guys help? I attach the config file and error message. I use v0.6.3 for windows 10. Thanks! Duc
 

Attachments

  • PeerlessRS28a.txt
    2.3 KB · Views: 11
  • ErrMsg.PNG
    ErrMsg.PNG
    13.2 KB · Views: 17

beneix

Member
2012-03-06 10:32 am
What would the disadvantages be of running CamillaDSP on a 32-bit system rather than a 64-bit one? Are there use cases where it makes no difference, for example a below a certain number of channels or number of chunks?

The Wiki mentions speed issues due to the 32-bit architecture having to deal with 64-bit floats, and also quotes some performance examples with different CPU loads.
In general, a 64-bit CPU and OS will perform better.

A few examples, done with CamillaDSP v0.5.0:


  • A Raspberry Pi 4 doing FIR filtering of 8 channels, with 262k taps per channel, at 192 kHz. CPU usage about 55%.
  • An AMD Ryzen 7 2700u (laptop) doing FIR filtering of 96 channels, with 262k taps per channel, at 192 kHz. CPU usage just under 100%.
Should this be interpreted that as long as your channel/chunk/tap requirements are not pushing the CPU beyond where you want it to be, the 32-bit system will be just as good for your requirements as a 64-bit?
 
Last edited:
What would the disadvantages be of running CamillaDSP on a 32-bit system rather than a 64-bit one?
The disadvantage is that you get 20-ish percent lower CPU performance overall. Also the asynchronous resampler can't use Neon on 32-bit, which costs another 20-30% for that one.
Should this be interpreted that as long as your channel/chunk/tap requirements are not pushing the CPU beyond where you want it to be, the 32-bit system will be just as good for your requirements as a 64-bit?
Yes exactly!
 
Dear Community, Henrik,
thank you for the amazing work. CamillaDSP makes sense.

My question: I intend to use Alsa only, do I have to install PulseAudio on a Linux Ubuntu server in order to run CamillaDSP's pre-built binary ?
And - more generally - what packages do I need to install on a debian machine to run CamillaDSP ?

Detailed context:
I want to set up a loudspeaker crossover with CamillaDSP.
I intent to use an older Linux Celeron PC on which I have installed the latest stable Ubuntu Server version - headless.
I had first to install Alsa (alsa; alsa-tools & alsa-utils I think), "speaker-test" now works on the 6 channels.
I have downloaded the camilladsp pre-built binary v1.0.0-alpha5.
When I start camilladsp I get "error while loading shared libraries: libpulse-simple.so.0: cannot open shared object file: No such file or directory".
I had understood I could use CamillaDSP on Alsa without Pulseaudio and I am reluctant to install too many packages on this machine unless needed. The "Dependencies" section of the main CamillaDSP readme file is cryptic to me - and seems focused on the self-build alternative.

Merci !
Daniel.
 
Last edited:

beneix

Member
2012-03-06 10:32 am
Tack Henrik. I am choosing between 32-bit and 64-bit for my RPi4 with HiFiBerry DAC+DSP. You rightly point out the issues with lack of Neon benefit etc., and it would be nicer to be able to use 64-bit. Since it looks like I need dsptoolkit in order for my sound card to work, I thought I was limited to 32-bit Raspbian – but this thread implicitly suggests that it might work on 64-bit, too (though of course the 64-bit version of Raspbian is not officially supported). If anyone has actually used this successfully I'd appreciate some confirmation.
 
Thank you Henrik.
Well, as I'm lazy, I opted for PulseAudio installation - I'd rather keep using CamillaDSP's convenient pre-built binary.
To do so, I decided to .. first make sure my previous installation of Alsa was complete - following directions from askUbuntu/how-do-i-run-pulseaudio-in-a-headless-server-installation:
Code:
sudo apt-get install libasound2 libasound2-plugins alsa-utils alsa-oss
Apt-get found out ibasound2-plugins & alsa-oss where missing. And pulled some other dependencies with it, including libpulse0.
Result: camilladsp now starts, problem solved.
Merci !
Daniel.
 
New version: v1.0.0-rc1
This is the first release candidate for v1.0.0.
Get it from here: https://github.com/HEnquist/camilladsp/releases/tag/v1.0.0-rc1

Changes from the last preview:
  • Clean up and remove unused config options
  • Handle subnormal numbers in IIR filters

Floating point numbers are stored in a normalized format, as a number called significand or mantissa, and an exponent. Subnormal numbers are the numbers with absolute values that are smaller than the smallest value that can be expressed this way. For 64-bit float, that means values smaller than about 2.2 *10^-308 (yes that is really small!). These are then stored in a special "subnormal" format. Most CPUs get much slower when doing math with subnormal numbers. "Much slower" can mean a factor 100!
This is normally not a problem, 2.2 *10^-308 is about -6000 dB (and for 32-bit floats the limit is about -760 dB). This only becomes a problem with IIR filters that process some signal that then becomes perfectly silent. IIR means the filter remembers the history (for a Biquad this is done via two stored numbers). At each iteration, the stored numbers become smaller and smaller, until at some point (typically a few seconds after the signal goes silent) they end up in the subnormal range. And then the filtering suddenly takes a lot more CPU. This version fixes this by flushing any subnormal number to zero after processing each chunk.