Henrik, a low priority request.
When plotting the pipeline, if "Collapse individual filters into filter steps" is selected then use the filter step "description" if it is not blank, as the label for the filter step in the plot. Then the combined filter step labels would be able to be read.
When plotting the pipeline, if "Collapse individual filters into filter steps" is selected then use the filter step "description" if it is not blank, as the label for the filter step in the plot. Then the combined filter step labels would be able to be read.
Please help to make camillaDSP/alsa-cdsp visible from system applications (pipewire)
Hello
I apologize if my question comes in the middle of a discussion. I am new in the use of CamillaDSP and just at the beginning of the reading of this long thread but can't wait to go further in camillaDSP use!
I just installed CamillaDSP with alsa-cdsp on a laptop under Fedora40 (recently installed). This (old) laptop is dedicated to that.
The installation seems correct. I followed the indications of the github pages using the script provided to install camilla. I compiled and installed the alsa-cdsp library. After some trials and errors I managed to adjust the content of a .asoundrc located in my home directory to have camillaDSP/alsa-cdsp running with a command like : aplay -D camilladsp sometrack.wav.
The configuration I use for camilladsp is very simple with gain and volume, just enough to check the sound played if going through calilladsp by reducing the gain of one channel.
The missing brick is having it visible from the system level (pipewire). The pcm.camilladsp created in .asoundrc is for now accessible only though a direct request like the example above. The pcm.camilladsp appears in no list : not in aplay -l, not under the volume/mixer control of Fedora (pactl?), not in the output an audio reader like Audacious can propose, not from pipewire (pw-top, helvum).
Can somebody help to add the missing link... or guide to a possible mistake?
Thanks a lot
Christian
PS : Thousands thanks to you Henrik and ?Scripple? to create, maintain, support such high quality software
Hello
I apologize if my question comes in the middle of a discussion. I am new in the use of CamillaDSP and just at the beginning of the reading of this long thread but can't wait to go further in camillaDSP use!
I just installed CamillaDSP with alsa-cdsp on a laptop under Fedora40 (recently installed). This (old) laptop is dedicated to that.
The installation seems correct. I followed the indications of the github pages using the script provided to install camilla. I compiled and installed the alsa-cdsp library. After some trials and errors I managed to adjust the content of a .asoundrc located in my home directory to have camillaDSP/alsa-cdsp running with a command like : aplay -D camilladsp sometrack.wav.
The configuration I use for camilladsp is very simple with gain and volume, just enough to check the sound played if going through calilladsp by reducing the gain of one channel.
The missing brick is having it visible from the system level (pipewire). The pcm.camilladsp created in .asoundrc is for now accessible only though a direct request like the example above. The pcm.camilladsp appears in no list : not in aplay -l, not under the volume/mixer control of Fedora (pactl?), not in the output an audio reader like Audacious can propose, not from pipewire (pw-top, helvum).
Can somebody help to add the missing link... or guide to a possible mistake?
Thanks a lot
Christian
PS : Thousands thanks to you Henrik and ?Scripple? to create, maintain, support such high quality software
This command lists hw devices, but the plugin is a pcm. You need "aplay -L".
I would actually recommend using the alsa loopback instead of the plugin. The plugin is useful for sample rate switching, but pipewire typically runs at a fixed sample rate. Then the loopback works well and is easier to set up.
Thank you for your quick answer.
Although the “aplay -D camilladsp sometrack.wav” command works, the pcm is not in the “aplay -L” list either... One minute I thought it depends if it was running or not, but no. Alsa is something opaque to me!
I started by testing camillaDSP with the plugin to avoid the question of oversampling/downsampling and let the file playing in its original sample rate. The default configuration of pipewire is with a fix 48k sample rate but it is very easy to set it to keep the original rate. This question of oversampling/downsampling has probably been discussed here or in other threads many times and there is even may be not a question? Is there a "common conclusion" on that?
As you suggest, I will test the loopback.
Christian
IMO the PCM device will have to be added to PW manually, IIUC PW lists only hw devices, not PCMs. Sth like https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1586
Hi,
For a newbie, where is the best place to start on CDSP, I'm very happy in Linux and have been playing with Pi's for years, I'm asking more about the "process", I currently have a MiniDSP SHD and I recall plugging in the UMIK-1 and running the DIRAC test and applying the results, how would I replicate that process and get better results with all those lovely channels (I'll probably use 5 initially, 2-way mains and a sub) with my RPi5 and HiFiBerry DAC8x?
Main source will be Roon.
Sorry for the newbie question.
Thanks.
RIchard
For a newbie, where is the best place to start on CDSP, I'm very happy in Linux and have been playing with Pi's for years, I'm asking more about the "process", I currently have a MiniDSP SHD and I recall plugging in the UMIK-1 and running the DIRAC test and applying the results, how would I replicate that process and get better results with all those lovely channels (I'll probably use 5 initially, 2-way mains and a sub) with my RPi5 and HiFiBerry DAC8x?
Main source will be Roon.
Sorry for the newbie question.
Thanks.
RIchard
Richard, Is this https://github.com/wirrunna/CamillaDSP-Building-a-Config what you are looking for ?
Great! It was the missing brick (link). Thank you.
This "adapter" is part of the pipewire.conf as example. Below is the minimum setting to have it working. Compare to the link provided, I had to declare a format. There is a bit more to dig around that, is a 32bits declaration correct letting to the last stage (Alsa) to do the job to format it for the sound card? I didn't check if channels and position are mandatory as I see no drawbacks to specify them.
Any way, the camilladsp pcm is now visible by the system in the mixer provided with the desktop (Fedora 40 Xfce4).
Only point is while switching between the possibilities offered by the desktop mixer (ie camilladsp to laptop card to camilladsp) under Audacious (it is the player I have for tests), the audio doesn't restart automatically when camilladsp is selected again. Need to stop Audacious and run it again. Not a big issue.
In the conf below "camillaIntel" (cf in path) is the name of the pcm I declared in the .asoundrc file. The reason of the name is I am testing the chain with the internal "Intel" sound card of the laptop. Next steps will be with an external usb dac.
Christian
Does someone want to try multithreaded filter processing? See: https://github.com/HEnquist/camilladsp/pull/362
The code is in branch "with_rayon" which is based on "next30".
The new mode is enabled via a new optional boolean "multithreaded" in the devices section of the config (that defaults to off). There is also the optional "worker_threads" to set the number of threads (defaults so the number of cores of the machine).
The idea is that between mixers and processors, each channel can be filtered independently from the others. So it collects the filters to apply to each channel, and then uses the really smart rayon library (https://crates.io/crates/rayon) to process the channels in parallel in a set of worker threads. Mixers and processors are still done in the main processing thread.
It needs quite heavy filter tasks to actually help, with too "easy" filters the overhead of passing things back and forth between threads gets larger than the actual processing time. Configs using many or very long FIR filters will likely gain from it, while configs with only a few biquads probably run slower.
The code is in branch "with_rayon" which is based on "next30".
The new mode is enabled via a new optional boolean "multithreaded" in the devices section of the config (that defaults to off). There is also the optional "worker_threads" to set the number of threads (defaults so the number of cores of the machine).
The idea is that between mixers and processors, each channel can be filtered independently from the others. So it collects the filters to apply to each channel, and then uses the really smart rayon library (https://crates.io/crates/rayon) to process the channels in parallel in a set of worker threads. Mixers and processors are still done in the main processing thread.
It needs quite heavy filter tasks to actually help, with too "easy" filters the overhead of passing things back and forth between threads gets larger than the actual processing time. Configs using many or very long FIR filters will likely gain from it, while configs with only a few biquads probably run slower.
Thanks, when designing a active bi-amped crossover/PEQ with CDSP, if using a DAC like the DAC8x with no "physical" volume control, are you doing volume control in CDSP, if so, is a fixed resistor voltage divider being used to "physically" cap the volume to prevent mishaps or glitches blowing drivers or deafening people?
My MiniDSP SHD feeds directly into my power amps and there was a glitch that used to occasionally send the SHD volume to 0dB (like the "volume up" remote command got "stuck"), luckily my power amps are pretty weak but it sure upset the family.
My MiniDSP SHD feeds directly into my power amps and there was a glitch that used to occasionally send the SHD volume to 0dB (like the "volume up" remote command got "stuck"), luckily my power amps are pretty weak but it sure upset the family.
I really like how clean and straightforward your implementation is. Also Rust really seems to help here a lot.
A question - would you consider a parallel resampler too? 🙂 But maybe the thread handling overhead would be too large here and since the resampler runs in the capture loop, it's quite time critical.
Richard, my implementation is based on https://www.audiosciencereview.com/forum/index.php?threads/rpi-camilladsp-tutorial.29656/.
Michael has put a lot of thought into his tutorial, and his recommended CamillaDSP service,
https://github.com/mdsimon2/RPi-CamillaDSP?tab=readme-ov-file#4-install-camilladsp-service ,
starts up at -40db. With my high efficiency K-Horns (105db/w at 1m) I start up at -60db. I use a FLIRC and an old Squeezebox remote to control volume in CamillaDSP and do not have any other limitation on the volume. So far I have not frightened anyone with a glitch. I learnt years ago that if you can't hear much out of the K-Horns at what should be a "normal" volume setting, check the input selection before you start playing with the volume.
You can see more on how I did it here - https://github.com/wirrunna/CamillaDSP-an-implemantation.
Rayon! It's really smart, don't know how I managed to overlook it before.
I'm planning to look at it, but it will take some redesigning to make the processing of channels more independent.
I tried the multithreader option and will keep it for the moment. For fun and to check stability, despite that it invokes a slightly higher total CPU load on my setup: RPi 3A+ steadily locked-clocked at 1GHz, RPiOS Bookworm lite. Signal path is mpd -->> CamillaDSP -->> aplay -->> Hifiberry SPDIF. CamillaDSP is compiled with Neon enabled. During playback, CamillaDSP performs a SR 44.1kHz -->> 96kHz upsampling and two channels convolution along with 128k FIR's.
Ironically the test results below stem from the playback of Eric Clapton's Double Trouble. Despite the song title, system playback was rock solid. Most critical/limiting in this (== my default) setup is FileCapture because of the chosen and demanding AsyncSinc resampler setting. Nota bene that for this kind of mpd playback there is absolutely no need for the AsyncSinc mode, the Synchronous mode would suit perfectly at a distintively lower CPU cost.
Multithreading set to false:
$ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
101843 101843 FF 10 camilladsp 144 1
101843 101845 FF 10 flexi_logger-fs 0.0 2
101843 101846 FF 10 flexi_logger-fl 0.0 0
101843 101847 FF 10 camilladsp 0.0 2
101843 101848 FF 10 camilladsp 56.8 1 (single convolution thread for both channels)
101843 101849 FF 10 FilePlayback 2.6 0
101843 101850 FF 10 FileCapture 84.7 2
Multithreading set to true:
$ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
102326 102326 FF 10 camilladsp 173 2
102326 102328 FF 10 flexi_logger-fs 0.0 2
102326 102329 FF 10 flexi_logger-fl 0.0 3
102326 102330 FF 10 camilladsp 0.0 1
102326 102331 FF 10 camilladsp 1.3 2
102326 102332 FF 10 FilePlayback 2.9 3
102326 102333 FF 10 FileCapture 91.5 1
102326 102334 FF 10 camilladsp 38.0 0 (convolution thread 1/2)
102326 102335 FF 10 camilladsp 36.4 2 (convolution thread 2/2)
102326 102336 FF 10 camilladsp 2.9 3
102326 102337 FF 10 camilladsp 1.3 0
Last edited:
Addendum:
Another setup with same base system, this time with the more appropriate and standard Synchronous upsampler type in case of mpd playback. CPU frequency can then be reduced to a locked minumum at f=600'000MHz, still with plenty of CPU reserves.
Multithreading set to false:
$ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
1607 1607 FF 10 camilladsp 96.9 1
1607 1609 FF 10 flexi_logger-fs 0.0 0
1607 1610 FF 10 flexi_logger-fl 0.0 0
1607 1611 FF 10 camilladsp 0.0 3
1607 1612 FF 10 camilladsp 80.6 2 (single convolution thread for both channels)
1607 1613 FF 10 FilePlayback 4.2 3
1607 1614 FF 10 FileCapture 11.9 1 (Synchronous type upsampling)
Multithreading set to true:
$ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
1765 1765 FF 10 camilladsp 114 2
1765 1767 FF 10 flexi_logger-fs 0.0 1
1765 1768 FF 10 flexi_logger-fl 0.0 2
1765 1769 FF 10 camilladsp 0.0 1
1765 1770 FF 10 camilladsp 1.3 3
1765 1771 FF 10 FilePlayback 4.4 1
1765 1772 FF 10 FileCapture 12.3 0 (Synchronous type upsampling)
1765 1775 FF 10 camilladsp 46.3 2 (convolution thread 1/2)
1765 1776 FF 10 camilladsp 44.0 3 (convolution thread 2/2)
1765 1777 FF 10 camilladsp 4.5 1
1765 1778 FF 10 camilladsp 2.2 1
Another setup with same base system, this time with the more appropriate and standard Synchronous upsampler type in case of mpd playback. CPU frequency can then be reduced to a locked minumum at f=600'000MHz, still with plenty of CPU reserves.
Multithreading set to false:
$ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
1607 1607 FF 10 camilladsp 96.9 1
1607 1609 FF 10 flexi_logger-fs 0.0 0
1607 1610 FF 10 flexi_logger-fl 0.0 0
1607 1611 FF 10 camilladsp 0.0 3
1607 1612 FF 10 camilladsp 80.6 2 (single convolution thread for both channels)
1607 1613 FF 10 FilePlayback 4.2 3
1607 1614 FF 10 FileCapture 11.9 1 (Synchronous type upsampling)
Multithreading set to true:
$ ps H -q $(pidof -s camilladsp) -o 'pid,tid,cls,rtprio,comm,pcpu,psr'
PID TID CLS RTPRIO COMMAND %CPU PSR
1765 1765 FF 10 camilladsp 114 2
1765 1767 FF 10 flexi_logger-fs 0.0 1
1765 1768 FF 10 flexi_logger-fl 0.0 2
1765 1769 FF 10 camilladsp 0.0 1
1765 1770 FF 10 camilladsp 1.3 3
1765 1771 FF 10 FilePlayback 4.4 1
1765 1772 FF 10 FileCapture 12.3 0 (Synchronous type upsampling)
1765 1775 FF 10 camilladsp 46.3 2 (convolution thread 1/2)
1765 1776 FF 10 camilladsp 44.0 3 (convolution thread 2/2)
1765 1777 FF 10 camilladsp 4.5 1
1765 1778 FF 10 camilladsp 2.2 1
Last edited:
Hi @HenrikEnquist,
apologies if I chime in this ongoing discussion.
I currently do not know how and where to post my problem.
I do have a Mac mini M2, 3 DACs combined in a main audio unit. Sampling rate can be 768khz 32bit.
I do have blackhole 16ch, which should also be capable of 768khz 32bit.
However when I set CamillaDSP to 768khz, Chunksize: 8192, resampling enabled AsyncSync, Accurate, Target Level 16383, I get pops and stutters. Using 384khz is working just fine.
I can reproduce this by letting my Mac starting the screensaver. During standard listening there are some pops, too.
I changed the chunk size a lot already, but nothing helped.
It might not be an issue - so I didn't want to raise one in Git.
It might just be my lack of understanding.
I learned that blackhole supports up to 16384 Buffer size.. that is why I set the target to nearly it.
If I set chunk size to 16384 this won't solve it either.
Maybe there is someone in this thread or you Henrik, who can guide me into the right direction.
That would be really much appreciated.
Thank you in advance for your help and this awesome piece of software.
Best regards,
Marius
apologies if I chime in this ongoing discussion.
I currently do not know how and where to post my problem.
I do have a Mac mini M2, 3 DACs combined in a main audio unit. Sampling rate can be 768khz 32bit.
I do have blackhole 16ch, which should also be capable of 768khz 32bit.
However when I set CamillaDSP to 768khz, Chunksize: 8192, resampling enabled AsyncSync, Accurate, Target Level 16383, I get pops and stutters. Using 384khz is working just fine.
I can reproduce this by letting my Mac starting the screensaver. During standard listening there are some pops, too.
I changed the chunk size a lot already, but nothing helped.
It might not be an issue - so I didn't want to raise one in Git.
It might just be my lack of understanding.
I learned that blackhole supports up to 16384 Buffer size.. that is why I set the target to nearly it.
If I set chunk size to 16384 this won't solve it either.
Maybe there is someone in this thread or you Henrik, who can guide me into the right direction.
That would be really much appreciated.
Thank you in advance for your help and this awesome piece of software.
Best regards,
Marius
USB DACs? This is not really recommended as they dont sync properly... should not "plop" but there has been showen that yet sway a bit time wise in this configuration. So not SOTA setup apparently...
//
Hey guys.
First, thanks Henrick and co, for this amazing software. It's brilliant!
Using
CamillaDSP 2.0.3
pyCamillaDSP 2.0.2
Backend 2.1.0,
running on ubuntu server, on a Intel® Quad-Core Processor J4125 (up to 2.7 GHz) machine, I get 40-50% dsp load (on one/4 cores) with 10 channels of 1200 taps@48khz and 10 channels 4800 taps@48khz.
When I tried doing 10 channels @48000 taps the thing just got stuck.
Do I have to adjust the chunk size?
Or is this a bad case of linux+intel high proccess loads?
When processing gets paused, all 4 cores are at 0 % load, so it must be camilladsp.
Thanks in advace!
First, thanks Henrick and co, for this amazing software. It's brilliant!
Using
CamillaDSP 2.0.3
pyCamillaDSP 2.0.2
Backend 2.1.0,
running on ubuntu server, on a Intel® Quad-Core Processor J4125 (up to 2.7 GHz) machine, I get 40-50% dsp load (on one/4 cores) with 10 channels of 1200 taps@48khz and 10 channels 4800 taps@48khz.
When I tried doing 10 channels @48000 taps the thing just got stuck.
Do I have to adjust the chunk size?
Or is this a bad case of linux+intel high proccess loads?
When processing gets paused, all 4 cores are at 0 % load, so it must be camilladsp.
Thanks in advace!