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
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
At the top of the output it should show your memory free and used. I edited my previous post with a screenshot of mine.ok. got it.
it just crashed again. Does this mean anything?
If you can take a screenshot, that is great. If not, list out what is output for "MiB Mem" and "MiB Swap".
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
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
I was just looking at your Config file. Your chnksize looks too low for a 96000 samplerate. The CamillaDSP Readme document recommends the following for chunksize:
Suggested starting points for different sample rates:
Suggested starting points for different sample rates:
- 44.1 or 48 kHz: 1024
- 88.2 or 96 kHz: 2048
- 176.4 or 192 kHz: 4096
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".
One more thing: Try setting your target_level to default.
https://github.com/HEnquist/camilla...arget_level (optional, defaults,the chunksize.
https://github.com/HEnquist/camilla...arget_level (optional, defaults,the chunksize.
@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.
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.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".
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.
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?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.
Thanks all! I've now changed a lot of things - no crashes so far.
Interesting - I think I can hear a subtle difference it sound when the resampling is turned on and off.
Interesting - I think I can hear a subtle difference it sound when the resampling is turned on and off.
Thank you so much, this really means a lot to me 🙂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.
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).
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.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?
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.I've just created an "issue" on the camilladsp github repository .... after testing with
- speaker-test --> pipewire loopback sink --> pipewire dac
The plan is to drop the pulse and jack backends, and replace them both with an improved pipewire backend.
Thank you!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.
There is something happening with the dac8x when coming out of the paused state. I have not had time to investigate yet. For now, don't use the silence timeout.I'm having an intermittent fault with my rpi5 and dac8x setup.
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
thanks HenrikI 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.
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 🙂
- Home
- Source & Line
- PC Based
- CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc