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

ok. got it.
it just crashed again. Does this mean anything?

1190 maraved+ -11 0 628480 14160 7680 S 2.3 0.3 17:37.38 camilladsp
86 root 20 0 0 0 0 I 1.3 0.0 0:00.40 kworker/u10:1-flush-179:0
2332 maraved+ 20 0 11968 5120 2560 R 0.3 0.1 0:00.22 top 1 root 20 0 169024 10672 7680 S 0.0 0.3 0:00.52 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pool_workqueue_release
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-rcu_g
5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-rcu_p
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-slub_
7 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-netns
11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker/u8:0-netns
12 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/R-mm_pe
13 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_kthread
14 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_rude_kthread
15 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_trace_kthread
16 root 20 0 0 0 0 S 0.0 0.0 0:00.23 ksoftirqd/0
17 root 20 0 0 0 0 I 0.0 0.0 0:00.17 rcu_preempt
18 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1
21 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/1
22 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/1
25 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2
 
top - 20:16:53 up 10:39, 3 users, load average: 0.07, 0.02, 0.00
Tasks: 202 total, 1 running, 201 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.4 us, 0.5 sy, 0.0 ni, 98.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 4050.9 total, 2926.0 free, 502.4 used, 710.8 buff/cache
MiB Swap: 512.0 total, 512.0 free, 0.0 used. 3548.5 avail Mem
 
@maravedis : Do you need the silencer? There are issues when recovering from the pause induced by the silencer. Your chunksize is just 5ms, workable but tight. I would suggest to try to disable the silencer by avoiding the silence_threshold config.

Also, do you need "Resampling". I.e., both your capture_samplerate and samplerate are set to 96000, so probably not. If not, I would set it to "none".
The capture and playback are different soundcards, their rate cannot be adjusted directly by rate adjust, the async resampler fine-tuned by the rate-adjust feedback is necessary and correct there.
 
  • Like
Reactions: TerryForsythe
IMO the target level at 384 for the chunksize of 512 is too low, very tight timing. It means the playback buffer when a new 512 chunk arrives should be on average at 3ms of data. That is an average, there will be deviations. Dangerously close to zero. I would recommend 3 chunk sizes for version 3.
 
  • Like
Reactions: mdsimon2
I have been enjoying the resources of DIYAudio for many years and there have been many fine projects presented but I do not think ANY have matched the grandeur of camilladsp. I can only imagine how beautiful its namesake must be.
Thank you so much, this really means a lot to me 🙂

BTW I added this at the beginning of the "Building" section of the readme, does it help?
Note: This section describes how to compile CamillaDSP from source. Only do this if you for some reason cannot use any of the pre-built binaries (see Installing).
 
My capture device is USB gadget, and my playback device is a MCHStreamer. I haven't noticed any issues with Resampling turned off. Should I be using it?
Please read the documentation https://github.com/HEnquist/camilladsp/, specifically the description of enable_rate_adjust config item. It explains why resampling is not required for the gadget and loopback devices.
 
  • Like
Reactions: TerryForsythe
I've just created an "issue" on the camilladsp github repository .... after testing with
  • speaker-test --> pipewire loopback sink --> pipewire dac
I will get to this eventually, but at the moment I don't have any system with pipewire installed. As a work around, can you let pipewire output to the alsa loopback, and let CamillaDSP capture from the alsa loopback? That avoids the somewhat outdated pulseaudio backend of camilladsp, and has the advantage that the alsa loopback can be synced to the hardware output device, so no async resampling is needed.

The plan is to drop the pulse and jack backends, and replace them both with an improved pipewire backend.
 
  • Like
Reactions: fb
ah right. I'll try that. I just took the values from mdsimon2's 44.1 template.

My tutorial uses 3X chunk size for target level, so for 512 chunk size I would use 1536 target level, not 384.

I do specify lower chunk sizes than Henrik as a starting point as I found they are OK with the hardware I use and I want reasonable latency for audio / video applications. Although every configuration is different, and you may require a greater chunk size for a specific use case.

If you don't care about latency (i.e. not an audio/video application), feel free to increase chunk size, but for configurations with rate adjust I would always make target level 3X chunk size.

Michael
 
I will get to this eventually, but at the moment I don't have any system with pipewire installed. As a work around, can you let pipewire output to the alsa loopback, and let CamillaDSP capture from the alsa loopback? That avoids the somewhat outdated pulseaudio backend of camilladsp, and has the advantage that the alsa loopback can be synced to the hardware output device, so no async resampling is needed.

The plan is to drop the pulse and jack backends, and replace them both with an improved pipewire backend.
thanks Henrik

I've tried reading from Loppback,1 via alsa ... success eludes for the moment .... once pipewire grabs Loopback,0 it also takes its' counterpart so cdsp crashes 🙁

permissions changes haven't worked yet, I'll keep trying alternate methods (never give up 🙂