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.
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..
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..
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.
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:
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:
Man, finding a way for the pulseaudio server to output through camilladsp in a useful fashion is getting pretty frustrating...
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: S24LE3Error 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 underrunMan, finding a way for the pulseaudio server to output through camilladsp in a useful fashion is getting pretty frustrating...
Ok so the idea is to apply the commits to the current source? I may try that.
Yes exactly. But the cdsp plugin is quite different from the bluealsa plugin it's based on so I don't think it will be possible to just apply the same commits. I think it will have to be done ḿanually.
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]
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..
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
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
Yes I saw that for example the code around the XRUN commit appears to be completely different which makes it very tricky.
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 added the following lines to /etc/default.pa:
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:
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...
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.
Code:
snd-aloopI 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 camilladspYou 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: S24LE3Note: 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:
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...
I just opensourced a CamillaDSP based project, which provides RME ADI-2 DAC like DSP flow.
See https://www.diyaudio.com/community/threads/camilladsp-monitor-a-rme-adi-2-dac-like-dsp-flow.383193/
See https://www.diyaudio.com/community/threads/camilladsp-monitor-a-rme-adi-2-dac-like-dsp-flow.383193/
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.
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.