Some interations, just for curiosity, about this theme, along with the system described above in post 5055 (running at 600MHz and multithreaded):
Chunksize = 1024 = 2^10
privat@PiMpd:~ $ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
31786 31786 FF 10 camilladsp 189 2
31786 31788 FF 10 flexi_logger-fs 0.0 0
31786 31789 FF 10 flexi_logger-fl 0.0 1
31786 31790 FF 10 camilladsp 0.0 3
31786 31791 FF 10 camilladsp 1.4 0
31786 31792 FF 10 FilePlayback 4.8 1
31786 31793 FF 10 FileCapture 12.8 0
31786 31794 FF 10 camilladsp 82.5 2
31786 31795 FF 10 camilladsp 70.1 0
31786 31796 FF 10 camilladsp 11.8 3
31786 31797 FF 10 camilladsp 6.7 1
Chunksize = 1027 = 13 * 79
privat@PiMpd:~ $ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
32918 32918 FF 10 camilladsp 203 2
32918 32920 FF 10 flexi_logger-fs 0.0 3
32918 32921 FF 10 flexi_logger-fl 0.0 1
32918 32922 FF 10 camilladsp 0.0 3
32918 32923 FF 10 camilladsp 1.6 3
32918 32924 FF 10 FilePlayback 4.5 0
32918 32925 FF 10 FileCapture 12.3 3
32918 32926 FF 10 camilladsp 77.3 2
32918 32927 FF 10 camilladsp 63.8 1
32918 32928 FF 10 camilladsp 24.1 1
32918 32929 FF 10 camilladsp 21.0 0
Chunksize = 1021 (prime)
privat@PiMpd:~ $ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
32362 32362 FF 10 camilladsp 214 1
32362 32364 FF 10 flexi_logger-fs 0.0 2
32362 32365 FF 10 flexi_logger-fl 0.0 2
32362 32366 FF 10 camilladsp 0.0 3
32362 32367 FF 10 camilladsp 1.9 2
32362 32368 FF 10 FilePlayback 4.5 2
32362 32369 FF 10 FileCapture 11.8 0
32362 32370 FF 10 camilladsp 85.9 3
32362 32371 FF 10 camilladsp 72.5 2
32362 32372 FF 10 camilladsp 22.3 1
32362 32373 FF 10 camilladsp 16.8 2
Chunksize = 2048 = 2^11
privat@PiMpd:~ $ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
28450 28450 FF 10 camilladsp 110 2
28450 28455 FF 10 flexi_logger-fs 0.0 0
28450 28456 FF 10 flexi_logger-fl 0.0 3
28450 28457 FF 10 camilladsp 0.0 1
28450 28458 FF 10 camilladsp 0.9 1
28450 28459 FF 10 FilePlayback 4.3 2
28450 28460 FF 10 FileCapture 11.9 3
28450 28461 FF 10 camilladsp 44.8 0
28450 28462 FF 10 camilladsp 42.6 1
28450 28463 FF 10 camilladsp 4.0 2
28450 28464 FF 10 camilladsp 1.9 2
Chunksize = 2047 = 23 * 89
privat@PiMpd:~ $ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
28922 28922 FF 10 camilladsp 127 1
28922 28924 FF 10 flexi_logger-fs 0.0 3
28922 28925 FF 10 flexi_logger-fl 0.0 0
28922 28926 FF 10 camilladsp 0.0 2
28922 28927 FF 10 camilladsp 1.6 3
28922 28928 FF 10 FilePlayback 4.4 3
28922 28929 FF 10 FileCapture 11.5 0
28922 28932 FF 10 camilladsp 54.1 2
28922 28933 FF 10 camilladsp 50.5 1
28922 28934 FF 10 camilladsp 4.7 3
28922 28935 FF 10 camilladsp 1.6 3
Chunksize = 2039 (prime)
privat@PiMpd:~ $ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
29426 29426 FF 10 camilladsp 151 2
29426 29428 FF 10 flexi_logger-fs 0.0 0
29426 29429 FF 10 flexi_logger-fl 0.0 3
29426 29430 FF 10 camilladsp 0.0 3
29426 29431 FF 10 camilladsp 2.9 0
29426 29432 FF 10 FilePlayback 4.7 3
29426 29433 FF 10 FileCapture 12.2 0
29426 29434 FF 10 camilladsp 65.2 1
29426 29435 FF 10 camilladsp 61.7 2
29426 29436 FF 10 camilladsp 5.0 0
29426 29437 FF 10 camilladsp 2.7 3
Chunksize = 4096 = 2^12
privat@PiMpd:~ $ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
33275 33275 FF 10 camilladsp 78.0 2
33275 33277 FF 10 flexi_logger-fs 0.0 0
33275 33278 FF 10 flexi_logger-fl 0.0 3
33275 33279 FF 10 camilladsp 0.0 0
33275 33280 FF 10 camilladsp 1.1 0
33275 33281 FF 10 FilePlayback 4.1 3
33275 33282 FF 10 FileCapture 14.5 0
33275 33283 FF 10 camilladsp 28.2 2
33275 33284 FF 10 camilladsp 16.5 0
33275 33285 FF 10 camilladsp 12.2 1
33275 33286 FF 10 camilladsp 1.1 3
Chunksize = 4087 = 61*67
privat@PiMpd:~ $ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
34215 34215 FF 10 camilladsp 101 2
34215 34217 FF 10 flexi_logger-fs 0.0 3
34215 34218 FF 10 flexi_logger-fl 0.0 1
34215 34219 FF 10 camilladsp 0.0 3
34215 34220 FF 10 camilladsp 2.2 3
34215 34221 FF 10 FilePlayback 4.0 2
34215 34222 FF 10 FileCapture 13.6 3
34215 34225 FF 10 camilladsp 40.4 1
34215 34226 FF 10 camilladsp 22.5 0
34215 34227 FF 10 camilladsp 18.1 3
34215 34228 FF 10 camilladsp 1.1 2
Chunksize = 4093 (prime)
privat@PiMpd:~ $ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
34006 34006 FF 10 camilladsp 127 0
34006 34008 FF 10 flexi_logger-fs 0.0 0
34006 34009 FF 10 flexi_logger-fl 0.0 1
34006 34010 FF 10 camilladsp 0.0 1
34006 34011 FF 10 camilladsp 3.1 2
34006 34012 FF 10 FilePlayback 4.4 1
34006 34013 FF 10 FileCapture 14.6 3
34006 34016 FF 10 camilladsp 52.3 0
34006 34017 FF 10 camilladsp 33.5 2
34006 34018 FF 10 camilladsp 20.2 1
34006 34019 FF 10 camilladsp 1.5 1
If you are running on a Raspberry Pi, then https://github.com/mdsimon2/RPi-CamillaDSP?tab=readme-ov-file#flirc-usb-ir-receiver will work. You will have to adapt the instructions for other platforms.
Hi,
Newbie here, layman's terms, so I picked up the HifiBerry DAC8X, something I read got me thinking...
Renne over at ASR was complaining in the "Multichannel audio on a Pi will get a whole lot easier and cheaper!" thread that the DAC8X was only 24-bit and in their words "24-bit dynamic + 8-bit volume control = 32-bit".
So I'm going to use the DAC8X (which (AFAIK) doesn't have hardware digital or analogue volume control) with CDSP as a digital crossover.
I'm thinking, not worried, does Renne make sense?
My basic understanding of DSP volume comes from Roon and I seem to remember it converts the audio bitrate to a 64-bit float internally (I think CDSP is similar) and therefore DSP volume is lossless as far as human hearing is concerned?
Am I missing something, it seems to me that say I have a 3-way stereo digital crossover, so 6 channels at 24-bit, so if I focus on mono, so 3 channels I have 72-bits covering the three drivers, LF, MF & HF but maybe it's not that simple and each channel has to cover the entire frequency range, not sure?
Thanks!
Newbie here, layman's terms, so I picked up the HifiBerry DAC8X, something I read got me thinking...
Renne over at ASR was complaining in the "Multichannel audio on a Pi will get a whole lot easier and cheaper!" thread that the DAC8X was only 24-bit and in their words "24-bit dynamic + 8-bit volume control = 32-bit".
So I'm going to use the DAC8X (which (AFAIK) doesn't have hardware digital or analogue volume control) with CDSP as a digital crossover.
I'm thinking, not worried, does Renne make sense?
My basic understanding of DSP volume comes from Roon and I seem to remember it converts the audio bitrate to a 64-bit float internally (I think CDSP is similar) and therefore DSP volume is lossless as far as human hearing is concerned?
Am I missing something, it seems to me that say I have a 3-way stereo digital crossover, so 6 channels at 24-bit, so if I focus on mono, so 3 channels I have 72-bits covering the three drivers, LF, MF & HF but maybe it's not that simple and each channel has to cover the entire frequency range, not sure?
Thanks!
Even the best dacs are only able to reproduce about 21 bits. The last bits are lost in noise, so if there are 24 or 32 to begin with doesn't matter.
The problem you could have, is if you have a lot of gain in you signal path and have to use very low volume settings. In this case, it may happen that the background noise from the DAC becomes audible. The solution is to simply reduce the gain somehow. There are passive inline attenuators you could use for example.
The same holds for subtractive dithering, I just wrote nonsubtractive dithering because subtractive dithering would make no sense in the context of that other thread. Subtractive dither means you subtract the dither from the quantized signal. That can sometimes be useful when you make a coarse ADC, but it makes no sense at all when you requantize a digital signal, as you would then end up with the original word length.
In other words, the types of dither used for digital requantization are always nonsubtractive.
In other words, the types of dither used for digital requantization are always nonsubtractive.
As Henrik already mentioned there are no DAC capable of using the calculated FP64 data. Eventually data will be truncated and presisission lost. Still there might be worth understanding the path used and try not to truncate back to 16-bit if possible. Where only 6.02 dB steps is possible with no loss.
There are some on this forum that advocate that there are no point calculate volume with higher presission than the DAC is capable of. Which make sence.
Still I've spendt some time tinkering with this topic and made a list of coefficient values that should return 24-bit or less values with no loss. A 1 dB stepped attunator could be bade using only 20-bit numbers.
In ATC I've implementet this idea with an option to send these known amplitude values from LMS to CamillaDSP. Please understand if CamillaDSP is doing what she is inteded to do, — calculate FB64 filters the amplitude change will probably not make much difference in the big scheme of things. https://github.com/StillNotWorking/LMS-helper-script/tree/main/atc
Fun fact, at least for me not being professional programmer. After som time with this project I learned it is possible to calculate attenuation step values from constants differented by how high resolution one need between each step. But in effort to make these coefficient accurate I had to calculate using integer and then convert integer as string to float. FP64 would always mess with the presission as professional know so well: http://www.indowsway.com/floatingpoint.htm
Hello,
Following a previous question (and its answer see #5049), I just set up Camilla with alsa_cdsp on a Debian 12 Xfce4 upgraded in pipewire 1.2. Everything runs fine.
I have a question linked to the Linux system to which Camilla is connected : Debian Xfce4 comes with a volume control available on the desktop. When I change this volume, I see the new value is known by pipewire/wireplumber (use wpctl status) but also by alsa (amixer sget Master) which let suppose there is only one volume somewhere.
I set the Camilla conf file with playback device: "hw:mycard" which I understand to be the lowest driver level (and I though it was straight = without transformation, to the usb). Where I am surprised is this system volume seems to operate after the input of Camilla in alsa as it modifies what is played though Camilla with a command like aplay -D camilladsp...
Can somebody explain the overall structure for the volume ? And by extension if other operations can occur within the hw plugin of alsa? Is the hw plugin the minimal one?
Thank you
Christian
Following a previous question (and its answer see #5049), I just set up Camilla with alsa_cdsp on a Debian 12 Xfce4 upgraded in pipewire 1.2. Everything runs fine.
I have a question linked to the Linux system to which Camilla is connected : Debian Xfce4 comes with a volume control available on the desktop. When I change this volume, I see the new value is known by pipewire/wireplumber (use wpctl status) but also by alsa (amixer sget Master) which let suppose there is only one volume somewhere.
I set the Camilla conf file with playback device: "hw:mycard" which I understand to be the lowest driver level (and I though it was straight = without transformation, to the usb). Where I am surprised is this system volume seems to operate after the input of Camilla in alsa as it modifies what is played though Camilla with a command like aplay -D camilladsp...
Can somebody explain the overall structure for the volume ? And by extension if other operations can occur within the hw plugin of alsa? Is the hw plugin the minimal one?
Thank you
Christian
Volume control is performed separately from the audio stream.
If your alsa device being set in PW as output offers hardware volume control (amixer -c your_hw_card sget Master), then IMO the path is volume widget GUI -> PW -> volume ctl of the active alsa output device.
If at the same time CDSP opens that particular hw card playback device and outputs samples, these are volume-adjusted by the actual hardware (typically its DAC chip with a volume feature). So CDSP plays the samples and PW handles the ctl controls of the same card. In fact lucky CDSP if it can open the playback device because often it's already open by PW.
You can see what processes have open which stream- and ctl- devices with 'lsof /dev/snd/*'. Typically PA/PW keeps the controlCx devices open, leaving opportunity for CDSP to open the stream device (pcmCxDyc/p).
If you want to avoid this collision, just disable the given device in PA/PW and the sound server will not touch the device in any way, leaving it fully available to other alsa clients.
If your alsa device being set in PW as output offers hardware volume control (amixer -c your_hw_card sget Master), then IMO the path is volume widget GUI -> PW -> volume ctl of the active alsa output device.
If at the same time CDSP opens that particular hw card playback device and outputs samples, these are volume-adjusted by the actual hardware (typically its DAC chip with a volume feature). So CDSP plays the samples and PW handles the ctl controls of the same card. In fact lucky CDSP if it can open the playback device because often it's already open by PW.
You can see what processes have open which stream- and ctl- devices with 'lsof /dev/snd/*'. Typically PA/PW keeps the controlCx devices open, leaving opportunity for CDSP to open the stream device (pcmCxDyc/p).
If you want to avoid this collision, just disable the given device in PA/PW and the sound server will not touch the device in any way, leaving it fully available to other alsa clients.
Thank you for your answer. I already saw in alsa documentation that there are "controls" without understanding what was behind.
As you suggested, the use of "lsof /dev/snd/*" helps a lot to understand who is doing what.
The controls are listed as /dev/snd/controlx (x = card number) while the audio stream are /dev/snd/pcmCxDyp (x = card number, y = device number).
In my setup, the controls are basically from wireplumber so the path you described. The volume adjusted by the widget is visible in alsamixer or through amixer.
It seems there is a mechanism of "back-annotation" (maybe not the right wword?) so that if the volume is changed thans to alsamixer for example, the widget value is refreshed. So the system remains consistent.
More interesting here is that if it is camilladsp which is playing (aplay -D camillapcm track.wav, camillapcm being the PCM in .asoundrc linked to alsacdsp), as expected, there is an audio stream to the card... but also a control coming from Camilla (see screenshot below). Currently, with my configuration, the volume is not changed by Camilla. The configuration I use is very simple, with only gains in the filters section.
So, to continue to have a better picture of the architecture, which component (filter type?) in Camilla could send something over control?... if it is camilladsp (other candidate alsacdsp?). In my conf file (ie .asoundrc), I haven't described control.
The first preview of v3.0.0 is ready!
camilladsp: https://github.com/HEnquist/camilladsp/releases/tag/v3.0.0-beta.1
gui: https://github.com/HEnquist/camillagui-backend/releases/tag/v3.0.0-beta.1
See the gui backend readme for how to install the gui and its dependencies:
https://github.com/HEnquist/camillagui-backend/tree/next30?tab=readme-ov-file#setting-up
Updated setup scripts will be available soon.
camilladsp: https://github.com/HEnquist/camilladsp/releases/tag/v3.0.0-beta.1
gui: https://github.com/HEnquist/camillagui-backend/releases/tag/v3.0.0-beta.1
See the gui backend readme for how to install the gui and its dependencies:
https://github.com/HEnquist/camillagui-backend/tree/next30?tab=readme-ov-file#setting-up
Updated setup scripts will be available soon.
Hi,
My first time playing with CDSP, how would I implement a 3.5-way for my system, approximate frequencies from the top of my head:
Ribbon: >4000Hz
Mid 1: 120-4000Hz
Mid 2: 120-500Hz?
Subwoofer: <120Hz
Basically I have the SVS 3000 Micro 8" sub and I want to build a compact sealed MTM with my ribbon and two 4-5" mid woofers.
Thanks.
My first time playing with CDSP, how would I implement a 3.5-way for my system, approximate frequencies from the top of my head:
Ribbon: >4000Hz
Mid 1: 120-4000Hz
Mid 2: 120-500Hz?
Subwoofer: <120Hz
Basically I have the SVS 3000 Micro 8" sub and I want to build a compact sealed MTM with my ribbon and two 4-5" mid woofers.
Thanks.
Thanks Henrik! I am sure I am missing something but I am running in to a few issues with the GUI.
When I load a configuration from V2 and I click the device tab I get a blank screen.
When I load a new blank configuration I can access the device tab but get some some errors that appear to be related to new properties.
Michael
Did you update pycamillasdsp and pycamilladsp-plot? They need to be the versions in the next30 branches.
I did, however looking back at the installation for pycamilladsp-plot it looks like it is installing 2.0.0 even though I am cloning from next30. pycamilladsp seems to install OK.
EDIT: Nevermind, I started from a completely new raspberry pi OS install and everything seems fine now. It still looks like it is installing V2.0.0 pycamilladsp-plot but that doesn't seem to cause an issue.
Michael
Code:
michael2@raspberrypi2:~/camilladsp $ git clone --branch next30 https://github.com/HEnquist/pycamilladsp-plot
Cloning into 'pycamilladsp-plot'...
remote: Enumerating objects: 917, done.
remote: Counting objects: 100% (174/174), done.
remote: Compressing objects: 100% (137/137), done.
remote: Total 917 (delta 82), reused 70 (delta 37), pack-reused 743 (from 1)
Receiving objects: 100% (917/917), 197.44 KiB | 1.84 MiB/s, done.
Resolving deltas: 100% (637/637), done.
michael2@raspberrypi2:~/camilladsp $ cd pycamilladsp-plot/
michael2@raspberrypi2:~/camilladsp/pycamilladsp-plot $ sudo pip3 install . --break-system-packages
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Processing /home/michael2/camilladsp/pycamilladsp-plot
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: PyYAML>=6.0 in /usr/local/lib/python3.11/dist-packages (from camilladsp_plot==2.0.0) (6.0.2)
Requirement already satisfied: jsonschema>=4.10 in /usr/lib/python3/dist-packages (from camilladsp_plot==2.0.0) (4.10.3)
Requirement already satisfied: attrs>=17.4.0 in /usr/lib/python3/dist-packages (from jsonschema>=4.10->camilladsp_plot==2.0.0) (22.2.0)
Requirement already satisfied: pyrsistent!=0.17.0,!=0.17.1,!=0.17.2,>=0.14.0 in /usr/lib/python3/dist-packages (from jsonschema>=4.10->camilladsp_plot==2.0.0) (0.18.1)
Building wheels for collected packages: camilladsp_plot
Building wheel for camilladsp_plot (pyproject.toml) ... done
Created wheel for camilladsp_plot: filename=camilladsp_plot-2.0.0-py3-none-any.whl size=58127 sha256=56cfd9e424bf314e6dfb43584158b511b6ffae825185b8e1a03c5ef62fc443d3
Stored in directory: /root/.cache/pip/wheels/e7/ad/8c/2c2c265175bf265f73efed9c506dfee7d6db8c683769b65fb2
Successfully built camilladsp_plot
Installing collected packages: camilladsp_plot
Attempting uninstall: camilladsp_plot
Found existing installation: camilladsp_plot 2.0.0
Uninstalling camilladsp_plot-2.0.0:
Successfully uninstalled camilladsp_plot-2.0.0
Successfully installed camilladsp_plot-2.0.0
Code:
michael2@raspberrypi2:~/camilladsp/pycamilladsp $ sudo pip3 install . --break-system-packages
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Processing /home/michael2/camilladsp/pycamilladsp
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: PyYAML>=6.0 in /usr/local/lib/python3.11/dist-packages (from camilladsp==3.0.0) (6.0.2)
Requirement already satisfied: websocket-client>=1.6 in /usr/local/lib/python3.11/dist-packages (from camilladsp==3.0.0) (1.8.0)
Building wheels for collected packages: camilladsp
Building wheel for camilladsp (pyproject.toml) ... done
Created wheel for camilladsp: filename=camilladsp-3.0.0-py3-none-any.whl size=38687 sha256=6f221c6c9bdbb97e8b1c1093ae0bd8234a3db5c0cdcd1f92637cd1cef015a6e9
Stored in directory: /tmp/pip-ephem-wheel-cache-d0h7qrxm/wheels/15/7b/10/d527e16feefd8c133e40d7079f0ba2b6102066457e9e2161c3
Successfully built camilladsp
Installing collected packages: camilladsp
Attempting uninstall: camilladsp
Found existing installation: camilladsp 2.0.2
Uninstalling camilladsp-2.0.2:
Successfully uninstalled camilladsp-2.0.2
Successfully installed camilladsp-3.0.0EDIT: Nevermind, I started from a completely new raspberry pi OS install and everything seems fine now. It still looks like it is installing V2.0.0 pycamilladsp-plot but that doesn't seem to cause an issue.
Michael
Last edited: