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

How do you determine if the incoming signal is clipped, if you don't hear it? Does camilladsp say it's clipping samples if fed by SPDIF signal? fi so, do you use resampling (I guess so...). Then the resampler might produce clipped samples (so called intersample overs), which is not a fault. Still the clipped samples should go away if using a mixer that turns down the signal on camilladsp's outputs.
 
Not in mine (app preinstalled in Samsung tv). But nevermind, i can live with it. Actually if it wasn't camilla's clipping counter I might not realize. Thank for all your work.
Ok.. but that counter should not be able to tell if the incoming spdif signal is clipped. The input is integer numbers, and all the possible values are vaild. This is caused by something else. Can you post your config?
 
I can reproduce the XRUN error in my Mint VM with the alsa_cdsp plugin. I get periodic XRUNs, all the time. With a small chunksize in camilladsp I also get the "stalled" warnings. With a larger chunksize (2048 at 48kHz for example) the stalled warnings go away, but XRUN stays the same.

I'm reading the plugin code to try to figure out what the problem is. First step is to make sure I fully understand how it works..
 
  • Like
Reactions: wineds
I have been investigating a bit but haven't had any success yet.
The alsa-cdsp plugin is based on a plugin from BlueALSA. That one has seen quite some changes that are not in alsa-cdsp (yet). One commit even mentions XRUN errors.
https://github.com/Arkq/bluez-alsa/commits/master/src/asound/bluealsa-pcm.cIt would probably be a good idea to update the plugin and to include the relevant changes. Unfortunately I don't have enough time to do any major work on the plugin myself.
 
I just noticed a similar thing happening when I use alsa loopback devices. Here's the input section of my camilladsp config:

Code:
devices:                                                                                                                                                          
  samplerate: 96000                                                                                                                                              
  chunksize: 4096                                                                                                                                                
  queuelimit: 1                                                                                                                                                  
  #enable_rate_adjust: true                                                                                                                                      
  enable_resampling: true                                                                                                                                        
  resampler_type: Synchronous                                                                                                                                    
  capture_samplerate: 44100                                                                                                                                      
  capture:                                                                                                                                                      
    type: Alsa                                                                                                                                                  
    channels: 2                                                                                                                                                  
    device: "plughw:Loopback,1,0"                                                                                                                                
    format: S32LE                                                                                                                                                
  playback:                                                                                                                                                      
    type: ALSA                                                                                                                                                  
    channels: 2                                                                                                                                                  
    device: "hw:U5,0"                                                                                                                                            
    format: S24LE3

Error rate decreases when using input device ""hw:Loopback,1,0" and format S16LE (must match the playback stream then because of missing conversions.

Here are the errors in camilladsp's log:
Code:
2022-02-14 22:53:10.638943 INFO [src/bin.rs:711] CamillaDSP version 1.0.0-rc2
2022-02-14 22:53:10.638963 INFO [src/bin.rs:712] Running on linux, x86_64
2022-02-14 22:53:10.645631 INFO [src/alsadevice.rs:547] Capture device supports rate adjust
2022-02-14 22:53:10.700201 INFO [src/alsadevice.rs:155] Starting playback from Prepared state
2022-02-14 22:53:12.912056 WARN [src/alsadevice.rs:151] Prepare playback after buffer underrun
2022-02-14 22:53:16.899173 WARN [src/alsadevice.rs:228] Wait timed out, capture device takes too long to capture frames
2022-02-14 22:53:17.014825 WARN [src/alsadevice.rs:228] Wait timed out, capture device takes too long to capture frames
2022-02-14 22:53:17.784049 WARN [src/alsadevice.rs:151] Prepare playback after buffer underrun

Man, finding a way for the pulseaudio server to output through camilladsp in a useful fashion is getting pretty frustrating...
 
I have been investigating a bit but haven't had any success yet.
The alsa-cdsp plugin is based on a plugin from BlueALSA. That one has seen quite some changes that are not in alsa-cdsp (yet). One commit even mentions XRUN errors.
https://github.com/Arkq/bluez-alsa/commits/master/src/asound/bluealsa-pcm.cIt would probably be a good idea to update the plugin and to include the relevant changes. Unfortunately I don't have enough time to do any major work on the plugin myself.
Ok so the idea is to apply the commits to the current source? I may try that.
 
I just noticed a similar thing happening when I use alsa loopback devices. Here's the input section of my camilladsp config:

Code:
devices:                                                                                                                                                         
  samplerate: 96000                                                                                                                                             
  chunksize: 4096                                                                                                                                               
  queuelimit: 1                                                                                                                                                 
  #enable_rate_adjust: true                                                                                                                                     
  enable_resampling: true                                                                                                                                       
  resampler_type: Synchronous                                                                                                                                   
  capture_samplerate: 44100                                                                                                                                     
  capture:                                                                                                                                                     
    type: Alsa                                                                                                                                                 
    channels: 2                                                                                                                                                 
    device: "plughw:Loopback,1,0"                                                                                                                               
    format: S32LE                                                                                                                                               
  playback:                                                                                                                                                     
    type: ALSA                                                                                                                                                 
    channels: 2                                                                                                                                                 
    device: "hw:U5,0"                                                                                                                                           
    format: S24LE3

Error rate decreases when using input device ""hw:Loopback,1,0" and format S16LE (must match the playback stream then because of missing conversions.

Here are the errors in camilladsp's log:
Code:
2022-02-14 22:53:10.638943 INFO [src/bin.rs:711] CamillaDSP version 1.0.0-rc2
2022-02-14 22:53:10.638963 INFO [src/bin.rs:712] Running on linux, x86_64
2022-02-14 22:53:10.645631 INFO [src/alsadevice.rs:547] Capture device supports rate adjust
2022-02-14 22:53:10.700201 INFO [src/alsadevice.rs:155] Starting playback from Prepared state
2022-02-14 22:53:12.912056 WARN [src/alsadevice.rs:151] Prepare playback after buffer underrun
2022-02-14 22:53:16.899173 WARN [src/alsadevice.rs:228] Wait timed out, capture device takes too long to capture frames
2022-02-14 22:53:17.014825 WARN [src/alsadevice.rs:228] Wait timed out, capture device takes too long to capture frames
2022-02-14 22:53:17.784049 WARN [src/alsadevice.rs:151] Prepare playback after buffer underrun

Man, finding a way for the pulseaudio server to output through camilladsp in a useful fashion is getting pretty frustrating...
The error basically means that the loopback isn't running as it should. Camilladsp waits for new samples by calling the Alsa function snd_pcm_wait() with a generous timeout. That should never fail on the loopback :/

I'm not sure what to expect in a VM, but in my Mint VM (in VirtualBox), the loopback has serious issues. Not sure what the problem is (and I haven't investigated). Unfortunately I don't have a spare machine I can try Mint on directly.
 
What are your recommended values for silence_threshold? Is it correct that camilladsp never goes into pause when it never received anything other than zero samples? If that's correct, would it be possible to add another silence algorithm than the current? The problem is that camilladsp never stops processing if it was started at system reboot and happily eats CPU time forever (and power) 🙂

Edit: You log output levels in DEBUG mode every 10s, could that be used to pause processing as well if all outputs report -1000 like this (and if silence_timeout is set), i.e. independent of the set silence_threshold:

2022-02-15 16:36:18.750859 DEBUG [src/alsadevice.rs:474] Playback buffer level: 3997.9, signal rms: [-1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0]
 
This seems like a bug, it's supposed to go to pause. I'll take a look.
The threshold isn't critical, -60 or something should do just fine.
It seems to pause properly for me. What are you capturing from? Is it possible that there is some signal on an unused input channel?

About using the level on the playback side to pause. That comes with the issue that if the processing gets paused, then there is nothing to monitor, and that makes it hard to know when to wake up and resume processing..
 
Ok.. but that counter should not be able to tell if the incoming spdif signal is clipped. The input is integer numbers, and all the possible values are vaild. This is caused by something else. Can you post your config?
hello and sorry for the late reply, needed to find the occasion to do this.
Really, this is a non issue for me, posting per your request in case you are curious.

Attached a screenshot showing the cippled samples counter (it is really difficult to take the screenshot right when the bars are red, but you can see the counter). Attached as well my config. As you can see, the resample is enabled. The song playing was "I didn't change my number" by Billie Eilish.
will try to observe if without resampling also clips. cheers.
 

Attachments

  • clipped 2.jpg
    clipped 2.jpg
    222.7 KB · Views: 114
  • config.pdf
    config.pdf
    55.8 KB · Views: 106
hello and sorry for the late reply, needed to find the occasion to do this.
Really, this is a non issue for me, posting per your request in case you are curious.

Attached a screenshot showing the cippled samples counter (it is really difficult to take the screenshot right when the bars are red, but you can see the counter). Attached as well my config. As you can see, the resample is enabled. The song playing was "I didn't change my number" by Billie Eilish.
will try to observe if without resampling also clips. cheers.

I would guess your convolution filters have boost and that is why your -3 dB gain in your mixer is not enough to prevent clipping. What does the convolution filter response look like?

Michael
 
It seems to pause properly for me. What are you capturing from? Is it possible that there is some signal on an unused input channel?

About using the level on the playback side to pause. That comes with the issue that if the processing gets paused, then there is nothing to monitor, and that makes it hard to know when to wake up and resume processing..
OK, I checked again and now it works, I must have messed up something in the config before. Sorry for the noise!

Btw, I'm capturing from the monitor device of a pulseaudio null sink. This is the only thing that works flawlessly here using linux mint. But that approach has two drawbacks:
a) pulseaudio has to do the first (synchronous) resampling step and because it never suspends (that only works for alsa devices) it will consume CPU time constantly, even if nothing is playing.
b) camilladsp has to do a second (asynchronous) resampling step because null sinks are timed by system clock and not by a soundcard's clock.

Soing resampling twice doe'snt feel right - though it's probably benign sound-wise. What bothers me more is that I have to stop camilladsp on my htpc after listening to music is done because this PC also acts as a web/cloud/mailserver and is running 24/7.

No showstopper for now, camilladsp is now running both on my laptop and my htpc with handmade configs. Hopefully PaXoverNG will be ready in the next few weeks... By then alsa-cdsp might have been fixed or I will have a go at it myself. That would still be the preferred route for me because it would eliminate the double-resampling using pulseaudio and also enable synchronous resampling only when using a alsa player. Would give some convenient options for people using PaXoverNG...
 
After getting the pulseaudio input to work i invested another 3h or so to give pulseaudio output to ALSA loopback and ALSA loopback input to camilladsp a try again. TLDR: it works now!

What was going wrong before?
  • I was using hw:Loopback,x,y, I had to switch to plughw:Loopback,x,y
  • when using module-udev-detect one cannot use an alsa sink with device="plughw:Loopback,0,0" or device="plughw:Loopback,1,0" as the "hw:Loopback,0,0" and "hw:Loopback,1,0"are detected by pulseaudio's udev-detect module as "Internal Audio" and seem to block usage of the corresponding plughw devices.
For the snd-aloop kernel module to load on boot you have to add the following line to /etc/modules :
Code:
snd-aloop

I added the following lines to /etc/default.pa:
Code:
load-module module-alsa-sink device="plughw:Loopback,1,1" sink_name=camilladsp sink_properties="device.description='CamillaDSP-Input'"
set-default-sink camilladsp

You can also copy the file /etc/pulse/default.pa to $HOME/.config/default.pa and make your modifications there. After modifying the default.pa you have to restart pulseaudio - or to be on the safe side - reboot.

And here's my Input/Output config for camilladsp:
Code:
devices:
  samplerate: 96000
  chunksize: 4096
  queuelimit: 1
  capture_samplerate: 96000
  silence_threshold: -35
  silence_timeout: 10
  capture:
    channels: 2
    type: Alsa
    device: "plughw:Loopback,0,1"
    format: FLOAT32LE
  playback:
    type: ALSA
    channels: 2
    device: "hw:U5,0"
    format: S24LE3

Note: I use FLOAT32LE as input format because I also let pulseaudio backend run with this format, so there is as few conversions done as possible, saves some CPU cycles.

Now everything works as expected, also after reboot. Only the camilldsp process has to be started obviously 🙂

Nice observation: Using ALSA input/output from pulseaudio to camilladsp uses approx. 70% less CPU time. Also the module-suspend-on-idle works as expected and after silence_timeout seconds the CPU-usage of the playback chain goes to zero.

Maybe this might be useful to somebody...
 
Last edited:
Yes you can use amixer. Depending on your setup you may need to specify which card to read from, instead of just reading the default. Unfortunately I use amixer so rarely that I completely forget how to use it in between 🙄
Maybe i don’t know something important but i find conflicting info about that. From the link https://github.com/HEnquist/camilladsp/issues/172 i find “
  • shairport-sync (or whatever) controls ALSA Loopback CTL mixer (which, by the way, does not attenuate the audio).

As far as i know and from other sources alsa mixer doesn’t know anything about loopback card volume control. It is absent. But the statement from the link talks a little diferent. What i am missing and where is the true? I am interested in loopback card, not other plugin type cards.
 
Regarding the alsa loopback stuff: I still got some occasional xruns with the previous setups (every 5-10min), so I decided to give linux mint's latest official low latency kernel a try. Now using it with the command line "chrt -r 90 camilladspsp camilladsp.config" and playing pink noise since 2.5h straigh without a single xrun (@96k, 16 channel out, chunksize 4096, queuelimit 1). will see how it behaves today night when gigabit backups from other PCs are rolling in onto this machine, this will be a real "torture" test...
 
  • Like
Reactions: wineds
Bummer. I randomly decide to see the latest here in a long time and it's people having trouble with the alsa_cdsp plugin. I've never seen the xrun problem but checked the code and noticed an integer math error which could be the cause. I posted a fix at least to the math. As I don't see the xruns on my boxes I can't say if it will fix the xrun problem or not. Please feel free to download the latest from github and see if it helps.

If the change doesn't help I suggest changing the "4" in if(xrun > 4) around line 320 to a larger value and seeing if that helps. If not I don't know what would fix it. You can get a lot more info if you compile with #define DEBUG 1 set to a larger value. 5 gives as it says in the code excessive amounts of information.

As to merging with bluez-alsa I think the bluez-alsa XRUN commit is just about keeping better track of the delay reported to the player. Really the behavior of the two was quite different when I was done anyway.
 
  • Like
Reactions: wineds