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

or in line with the intent of the shortcut page
The idea behind the current implementation was to start simple to see what happens. This is actually the first feedback I have gotten 🙂
Adding toggle switches would be logical. Same with allowing a control to modify more than one setting. I was thinking of also making it possible to invert the action for selected settings, so dragging a slider increases one setting while decreasing another, or a flipping a toggle switches one boolean to true and another to false.
 
Thanks for the feedback Wirrunna. I read your comment on audiosciencereview and its great to know that CamillaDSP is able to execute on the Raspberry Pi Zero 2 W. Processing power seems to be almost up to par with the RPi 3b but I am still a bit worried about the limited amount of RAM. Especially reading your comment about the need for increased swap space. I don't want a swap file but I guess 64bit Raspberry Pi OS Lite is a bit more memory hungry than my buildroot generated OS. I just had to check before I order a RPi Zero 2 W and here are some figures running on a RPi 4b with 2GB RAM, 64bit Linux using the cut-down version start4cd.elf with a gpu_mem=16 memory split and no swap file. Busybox is used for init, syslogd, crond, getty etc., mdev for device management and dropbear for sshd. The most barebone configuration does not start networking, dropbear or cron and the free command output looks like this:

Code:
total        used        free      shared  buff/cache   available
Mem:        1942296       38052     1873264          16       30980     1876492
Swap:             0           0           0

And the top command output looks like this (sorted on memory use):

Code:
Mem: 67044K used, 1875252K free, 16K shrd, 8K buff, 11872K cached
CPU:   0% usr   0% sys   0% nic  99% idle   0% io   0% irq   0% sirq
Load average: 0.00 0.00 0.00 2/137 188
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
  178     1 root     S     271m  14%   0% /usr/sbin/camilladsp -a 127.0.0.1 -p 1
  129     1 root     S     3332   0%   0% /sbin/mdev -df
  188   179 root     R     2940   0%   0% top
    1     0 root     S     2940   0%   0% init
  179     1 root     S     2940   0%   0% -sh
  117     1 root     S     2940   0%   0% /sbin/syslogd -n -K
  180     1 root     S     2940   0%   0% /sbin/getty -L tty1 0 vt100
   41     2 root     IW       0   0%   0% [kworker/u9:1-ev]
   53     2 root     IW       0   0%   0% [kworker/1:1-mm_]
    2     0 root     SW       0   0%   0% [kthreadd]
   69     2 root     IW       0   0%   0% [kworker/u9:3-ev]
   82     2 root     IW<      0   0%   0% [kworker/0:1H-mm]
  140     2 root     IW       0   0%   0% [kworker/u11:1-e]
    3     2 root     SW       0   0%   0% [pool_workqueue_]
    4     2 root     IW<      0   0%   0% [kworker/R-rcu_g]
    5     2 root     IW<      0   0%   0% [kworker/R-rcu_p]
    6     2 root     IW<      0   0%   0% [kworker/R-slub_]
    7     2 root     IW<      0   0%   0% [kworker/R-netns]
    8     2 root     IW       0   0%   0% [kworker/0:0-eve]
    9     2 root     IW<      0   0%   0% [kworker/0:0H-ev]

Feels like I got plenty of RAM left and no need for a swap file, not even on a RPi Zero 2 W with only a quarter of RAM.

This is what it looks like adding network and the equivalence of dhcpd, sshd and crond (not too bad):

Code:
Mem: 72508K used, 1869788K free, 32K shrd, 8K buff, 14812K cached
CPU:   0% usr   0% sys   0% nic  99% idle   0% io   0% irq   0% sirq
Load average: 0.02 0.01 0.00 2/131 438
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
  173     1 root     S     271m  14%   0% /usr/sbin/camilladsp -a 127.0.0.1 -p 1
  129     1 root     S     3332   0%   0% /sbin/mdev -df
    1     0 root     S     2940   0%   0% init
  205     1 root     S     2940   0%   0% udhcpc -t1 -A3 -b -R -O search -O stat
  428   336 root     R     2940   0%   0% top
  336     1 root     S     2940   0%   0% -sh
  117     1 root     S     2940   0%   0% /sbin/syslogd -n -K
  210     1 root     S     2940   0%   0% /usr/sbin/crond -f
  219     1 root     S     2940   0%   0% /sbin/getty -L tty1 0 vt100
  217     1 root     S     2644   0%   0% /usr/sbin/dropbear -R
  401     2 root     IW       0   0%   0% [kworker/2:0-eve]
   41     2 root     IW       0   0%   0% [kworker/u9:1-ev]
  203     2 root     IW       0   0%   0% [kworker/1:2-eve]
    8     2 root     IW       0   0%   0% [kworker/0:0-pm]
   17     2 root     IW       0   0%   0% [rcu_preempt]
   47     2 root     SW       0   0%   0% [kcompactd0]
   69     2 root     IW       0   0%   0% [kworker/u11:1-e]
   94     2 root     IW<      0   0%   0% [kworker/0:1H-mm]
   99     2 root     SW       0   0%   0% [f2fs_gc-179:2]
    2     0 root     SW       0   0%   0% [kthreadd]

I hope sharing these figures can be of help for someone...
 
@phofman : good to know even though I’m pretty stuck on the RPi platform since I use a HiFiBerry DAC+ ADC for this build. Hopefully it translates to the RPi Zero...

The reason I’m considering the Zero is it’s power efficiency. About 120 mA @ 5V, or 600 mW idling. It makes me reevaluate the need for external power control of the RPi. I will still use a MC to power cycle dual rails to analog RIAA amp (and its transformer) and manage a trigger to my power amp (for power control), but I could let the RPi Zero run 24/7 (maybe use cron to power cycle once a week during night time if needed for stability). I just want to make sure I don’t trash my SD card running 24/7. I already syslog to the kernel ring buffer but I want to be able to run without a swap file on the SD-card…
 
CamillaDSP x86_64 2.0.3
Windows 11

Does CamillaDSP has some sort of auto-mute function? And if so, is there a way to turn this off?

I'm trying out a project where I use CamillaDSP to perform some complex filtering on files using multiple FIR convolutions. To avoid gaps caused by FIR windowing I combine the tracks, convert the samplerate and convert the files to raw format using sox, send them to CDSP, which outputs a raw file which is then converted back and split up by sox. All seemed fine until I tried a file with had digital silence embedded at the end of the track. This came back truncated. I overwrote the digital silence with low-level white noise and found that noise with an average RMS level of -72.7dBFS causes truncation. If I increase the level (of the noise only) by 0.2dB, then CDSP doesn't truncate.

I've done extensive tests and this isn't being caused by sox - I ran the script without invoking CDSP and the files come through fine. If I just create the raw file and send it to CDSP by running the command at a terminal session, then it comes back truncated.

I've attached two sample flacs, one causes truncation and the other doesn't. I've also attached the config I'm using. Oddly, If send 'Truncates' through on its own, it gets cut to 8s (the original file is 16s long). If I combine the two (with 'Doesnt Truncate' first) then split the output, then 'Doesnt Truncate' is fine and the correct length, but 'Truncate' is now 12s long.

Anyone have any idea how to prevent this happening?

[Also ... WTF?!?]
 

Attachments

Is it possible to assign a custom shortcut slider to more than one config setting ?
It looks like the custom shortcuts are limited to numerical values and used with sliders
I have done both of these now, to be included in the 3.0 release.
Defining the shortcuts like this:

shortcut_def.png

Produces this in the GUI:
custom_shortcuts.png

The little alert icon is shown when there is some issue, and hovering over it shows an explanation.
That can be that some property in the config value isn't at the expected value (for example that the highpass and lowpass filters are set to different frequencies), or that not all paths are present in the config.
 
Would this 10 band graphic equalizer filter go from vertical sliders to horizontal ?
10band_graphic.jpg

I don't use it, but built it out of curiosity. However, I could see a custom version of a graphic equalizer appealing as the slider would take effect immediately rather than requiring a restart.
 
I'm trying to make a dedicated rPi5 USB DSP using CamillaDSP, as mentioned in other threads here.
All is working ok, including USB gadget.

I've run into one problem, though: The DIYINHK multichannel dac (XMOS based) is recognised ok and is listed as an output device (see screenshot). But after this, enormously loud pops come from all channels (the speaker cones move dramatically, I have to switch off the amplifier to prevent the drivers from blowing up).
This repeats every 4 seconds or so, until I change some settings in Camilla DSP on the output device.
Even when I disconnect USB, the pops continue, as if the XMOS is crashing.
It occurs when booting, as well as when connecting it after boot.

After some fiddling in CamillaDSP, the pops stops, and all works fine! Very strange. It seems like the XMOS needs to receive some commands from the rPi to behave itself........?

I read on github that @mdsimon2 got his DIYINHK to work, but that on the OKTODAC8PRO (which also uses the DIYINHK XMOS firmware) some firmware versions gave problems.
Is there a way to solve this?
 

Attachments

  • Schermafbeelding 2024-08-14 135524.jpg
    Schermafbeelding 2024-08-14 135524.jpg
    203.6 KB · Views: 54
I have done both of these now, to be included in the 3.0 release.

Thanks ! I was also needing a cross fade so this should work well.

Maybe this is not practical or unnecessarily complex but I am wondering if the “reverse” could instead be a python equation using the user value/Boolean input and other config settings. Reversing would use the not operator.
 
The DIYINHK multichannel dac (XMOS based) is recognised ok and is listed as an output device (see screenshot). But after this, enormously loud pops come from all channels
I would guess that there is some problem with the implementation of that dac. Are the pops synced with buffer underruns in camilladsp?
I am using the DIYINHK XMOS multichannel usb to i2s board in my diy dac, with a couple of PCM1794 stereo dac boards. It's working very well without any pops.
 
Maybe this is not practical or unnecessarily complex but I am wondering if the “reverse” could instead be a python equation using the user value/Boolean input and other config settings. Reversing would use the not operator.
This is evaluated in the frontend, so it's javascript rather than python. There are libraries for safe and fast evolution of math expressions, so it could certainly be done. However it makes things quite a bit more complicated. You would actually need to provide two equations, one "forward" for calculating the config values from the slider position, and one "inverse" for calculating the slider position from the config values. Both also need to be correct, otherwise things may get quite weird.

Crossfade probably works better if the gain filters are set to linear gain instead of dB.
 
Would this 10 band graphic equalizer filter go from vertical sliders to horizontal ?

I don't use it, but built it out of curiosity. However, I could see a custom version of a graphic equalizer appealing as the slider would take effect immediately rather than requiring a restart.
It would work yes, but a bit clunky to set up. You can enable "apply automatically" to get the normal graphical equaliser to take effect immediately.
 
  • Like
Reactions: Wirrunna
There are libraries for safe and fast evolution of math expressions, so it could certainly be done. However it makes things quite a bit more complicated
Thanks for the explanation, I did not appreciate the added level of complexity of my suggestion.

For my application, the current implementation should work fine. I will install the next3.0 and give it a try.
 
I'm trying to make a dedicated rPi5 USB DSP using CamillaDSP, as mentioned in other threads here.
All is working ok, including USB gadget.

I've run into one problem, though: The DIYINHK multichannel dac (XMOS based) is recognised ok and is listed as an output device (see screenshot). But after this, enormously loud pops come from all channels (the speaker cones move dramatically, I have to switch off the amplifier to prevent the drivers from blowing up).
This repeats every 4 seconds or so, until I change some settings in Camilla DSP on the output device.
Even when I disconnect USB, the pops continue, as if the XMOS is crashing.
It occurs when booting, as well as when connecting it after boot.

After some fiddling in CamillaDSP, the pops stops, and all works fine! Very strange. It seems like the XMOS needs to receive some commands from the rPi to behave itself........?

I read on github that @mdsimon2 got his DIYINHK to work, but that on the OKTODAC8PRO (which also uses the DIYINHK XMOS firmware) some firmware versions gave problems.
Is there a way to solve this?

It has been a while since I used the DIYINHK XMOS with a raspberry pi but it seemed to have issues compared to using it with a Mac. I was using a RPi4 and found some of the insane popping / squealing observed on restarts went away if using the USB2 ports instead of USB3 ports, I haven't tried it on the RPi5 so not sure if it is similar.

I don't think Okto have used the DIYINHK XMOS firmware for a while now, definitely not in FW 1.5 or 1.6. Although I've never had any popping issues with the Okto on FW 1.42, 1.5 or 1.6.

Michael
 
  • Like
Reactions: marcelooms