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.
Is it possible to run CamillaDSP on a Raspberry Pi Zero 2 W? I searched this thread and the Internet but came up short. If anyone has tried please share your experience (especially CPU and RAM utilization, need for swap or not etc.)... Thanks in advance 🙂
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:
And the top command output looks like this (sorted on memory use):
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):
I hope sharing these figures can be of help for someone...
Code:
total used free shared buff/cache available
Mem: 1942296 38052 1873264 16 30980 1876492
Swap: 0 0 0And 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...
@EmuMannen : CDSP runs fine on Rock Pi S with 512MB RAM, no swap needed. Memory is lacking there when installing kernel with some debian DKMS builds, then swap is needed (actually just zram using the same RAM).
@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…
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…
Yes, I gave it as an example of a 512MB RAM system running CDSP OK. RPi Zero is a comparable device in terms of parameters, IMO it will run just fine.
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?!?]
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?!?]
Yes, you have asked for it:
After 3 seconds below -60dB, it will start dropping the silent data.
Just remove those lines from the config.
I have done both of these now, to be included in the 3.0 release.
Defining the shortcuts like this:
Produces this in the GUI:
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 ?
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 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?
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
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.
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.
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.
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.
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.
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