I don't have the app so can't test it, but in all screenshots the cells are always blue. I think it's just on/off, there are no other parameters like gain.
I have added the gain as numbers in each cell, looks ok.
The colors indicate gain now, which I kinda like. But with the gain shown as a number, that's not really necessary. There could be three different colors to show normal, inverted, and muted.
Yes something like this could work.
Those can only show like 4-5 different values, is that enough to be useful?
I really like the latest format for the mixer.
For my use, I do prefer gain value in numbers as opposed to color as I mostly only use a limited range for crossover gain settings. If you can fit in the channel labels I think that would be very useful. Not sure we need both the "input"/ "output" as well as the arrows. Personally, I find only having "input" and "output" clear enough. Do we still need the "+" ?
Yet another possible option for muted is having the gain value in cross out format.
For my use, I do prefer gain value in numbers as opposed to color as I mostly only use a limited range for crossover gain settings. If you can fit in the channel labels I think that would be very useful. Not sure we need both the "input"/ "output" as well as the arrows. Personally, I find only having "input" and "output" clear enough. Do we still need the "+" ?
Yet another possible option for muted is having the gain value in cross out format.
I have added the channel labeling to some of my configs, I find it really helps with the readability of the pipeline viewer and also when making modifications to the pipeline.
I did noticed that the last mixer labels are carried over to the output device. I like to see to where the signals are going to my device in terms of its own channel designation which for me is channel number. So in my case, I would prefer to keep the channel # or the possibility of custom labels similar to what is implemented for the capture device. Custom labels might also be useful to provide interface cards surround sound channel setup.
When I was adding the labels to my configs, there were a few occasions that I did wish for a slightly larger field for the channel labels in the pipeline viewer. I think I got up to 7 characters, 10 or 12 would have permitted more explicit labels to be viewed. Something to consider although I understand screen real estate is at a premium in the pipeline viewer. Alternatively, maybe hover over could expose full length label ?
I did noticed that the last mixer labels are carried over to the output device. I like to see to where the signals are going to my device in terms of its own channel designation which for me is channel number. So in my case, I would prefer to keep the channel # or the possibility of custom labels similar to what is implemented for the capture device. Custom labels might also be useful to provide interface cards surround sound channel setup.
When I was adding the labels to my configs, there were a few occasions that I did wish for a slightly larger field for the channel labels in the pipeline viewer. I think I got up to 7 characters, 10 or 12 would have permitted more explicit labels to be viewed. Something to consider although I understand screen real estate is at a premium in the pipeline viewer. Alternatively, maybe hover over could expose full length label ?
Are there any simple way to restore the linuxinstallation (Ubuntu) or uninstall CamillaDSP and reset all configfiles?
I'm trying another DSP solution, however are I not ably to use any other output than via CamillaDSP?
I have been using CamillaDSP several years now and I can not remember all the changes I made to get it working.
Perhaps is it easiest to reinstall Ubunto from scratch?
I'm trying another DSP solution, however are I not ably to use any other output than via CamillaDSP?
I have been using CamillaDSP several years now and I can not remember all the changes I made to get it working.
Perhaps is it easiest to reinstall Ubunto from scratch?
I have a question, I wonder if anyone has asked it before?
When I modify the settings on the CDSP GUI, such as adjusting the filter, gain, beq, etc. in the Pipeline, the delay of the CDSP will increase, about 15-50ms. At this time, restart the CDSP, and the delay returns to the same as at the beginning.
I use REW to test the delay, and the reference channel is the speaker without passing through the CDSP.
When I modify the settings on the CDSP GUI, such as adjusting the filter, gain, beq, etc. in the Pipeline, the delay of the CDSP will increase, about 15-50ms. At this time, restart the CDSP, and the delay returns to the same as at the beginning.
I use REW to test the delay, and the reference channel is the speaker without passing through the CDSP.
Are you using a graphical ui with pulseaudio or pipewire? Then you will need undo any changes you have made to the pulse or pipewire config files.
If not, you probably just have an alsa config in your home dir. Try just renaming that file.
This is my yml file:
Code:
description: null
devices:
adjust_period: null
capture:
channels: 10
device: hw:Pre,0,0
format: S32LE
type: Alsa
capture_samplerate: 96000
chunksize: 256
enable_rate_adjust: null
playback:
channels: 8
device: hw:Pre,0,0
format: S32LE
type: Alsa
queuelimit: 4
rate_measure_interval: null
resampler: null
samplerate: 96000
silence_threshold: -100
silence_timeout: 0
stop_on_rate_change: false
target_level: null
volume_ramp_time: null
filters:
"LFE\u4F4E\u5207":
description: null
parameters:
freq: 11
q: 0.8
type: Highpass
type: Biquad
"LFE\u589E\u52A0\u97F3\u91CF":
description: null
parameters:
gain: 0
inverted: false
mute: false
scale: dB
type: Gain
"\u524D\u4E09\u4F4E\u5207":
description: null
parameters:
freq: 60
order: 6
type: ButterworthHighpass
type: BiquadCombo
"\u5377\u79EF\u4E2D":
description: null
parameters:
channel: 0
filename: ../coeffs/Filters C-96k.wav
type: Wav
type: Conv
"\u5377\u79EF\u53F3":
description: null
parameters:
channel: 0
filename: ../coeffs/Filters R-96k.wav
type: Wav
type: Conv
"\u5377\u79EF\u5DE6":
description: null
parameters:
channel: 0
filename: ../coeffs/Filters L-96k.wav
type: Wav
type: Conv
"\u5377\u79EF\u70AE":
description: null
parameters:
channel: 0
filename: ../coeffs/LEF Vector-96k.wav
type: Wav
type: Conv
"\u589E\u52A0\u8F93\u51FA\u4E2D\u7F6E":
description: null
parameters:
gain: 3
inverted: false
mute: false
scale: dB
type: Gain
"\u589E\u52A0\u8F93\u51FA\u53F3\u4E3B\u7BB1":
description: null
parameters:
gain: 2
inverted: false
mute: false
scale: dB
type: Gain
"\u589E\u52A0\u8F93\u51FA\u5DE6\u4E3B\u7BB1":
description: null
parameters:
gain: 3
inverted: false
mute: false
scale: dB
type: Gain
"\u5EF6\u65F6\u4E2D\u7F6E":
description: null
parameters:
delay: 4.5
subsample: false
unit: ms
type: Delay
"\u5EF6\u65F6\u70AE":
description: null
parameters:
delay: 170.23
subsample: false
unit: ms
type: Delay
"\u9759\u97F3":
description: null
parameters:
gain: -100
inverted: false
mute: true
scale: dB
type: Gain
mixers:
10x8:
channels:
in: 10
out: 8
description: null
mapping:
- dest: 0
mute: false
sources:
- channel: 0
gain: 0
inverted: false
mute: false
scale: dB
- dest: 1
mute: false
sources:
- channel: 1
gain: 0
inverted: false
mute: false
scale: dB
- dest: 2
mute: false
sources:
- channel: 2
gain: 0
inverted: false
mute: false
scale: dB
- dest: 3
mute: false
sources:
- channel: 3
gain: 0
inverted: false
mute: false
scale: dB
pipeline:
- bypassed: null
description: "\u58F0\u5361\u8DEF\u7531"
name: 10x8
type: Mixer
- bypassed: null
channel: 1
description: "\u5DE6\u4E3B\u7BB1"
names:
- "\u524D\u4E09\u4F4E\u5207"
- "\u5377\u79EF\u5DE6"
- "\u589E\u52A0\u8F93\u51FA\u5DE6\u4E3B\u7BB1"
type: Filter
- bypassed: null
channel: 2
description: "\u4E2D\u7F6E"
names:
- "\u524D\u4E09\u4F4E\u5207"
- "\u5377\u79EF\u4E2D"
- "\u589E\u52A0\u8F93\u51FA\u4E2D\u7F6E"
type: Filter
- bypassed: null
channel: 0
description: "\u53F3\u4E3B\u7BB1"
names:
- "\u524D\u4E09\u4F4E\u5207"
- "\u5377\u79EF\u53F3"
- "\u589E\u52A0\u8F93\u51FA\u53F3\u4E3B\u7BB1"
type: Filter
- bypassed: null
channel: 3
description: "\u70AE\u4F4E\u5207"
names:
- "LFE\u4F4E\u5207"
- "\u5377\u79EF\u70AE"
- "LFE\u589E\u52A0\u97F3\u91CF"
type: Filter
- bypassed: null
channel: 3
description: "\u4F4E\u97F3\u70AE"
names: []
type: Filter
processors: {}
title: "zorg\u2018s DSP"Thanks, that's a decent CPU performance. Your setup is not not trivial (10ch in, 8ch out, 96kHz, 256 frames chunksize), what is the CPU load with CDSP running?
IIUC the CDSP processing thread receives the config-change message between audio chunk messages and does the pipeline/processing reconfiguration before processing next chunk, without any pausing the chain, very nice design. IIUC the next processed chunk from Processing will be delivered to Playback with a bit of delay, taken by the reconfiguration. But 30ms is a very long time, IMO the reconfiguration should take much less on your CPU.
Also with the configured 256 chunksize @ 96kHz (2.6ms chunk time) the playback buffer will be 5 - 10ms long. A delay of 30ms would definitely cause buffer underruns in Playback. Do you see any buffer issues in your CDSP log? Actually the log when the issue happens (preferrably debug level) would be very useful.
IIUC the CDSP processing thread receives the config-change message between audio chunk messages and does the pipeline/processing reconfiguration before processing next chunk, without any pausing the chain, very nice design. IIUC the next processed chunk from Processing will be delivered to Playback with a bit of delay, taken by the reconfiguration. But 30ms is a very long time, IMO the reconfiguration should take much less on your CPU.
Also with the configured 256 chunksize @ 96kHz (2.6ms chunk time) the playback buffer will be 5 - 10ms long. A delay of 30ms would definitely cause buffer underruns in Playback. Do you see any buffer issues in your CDSP log? Actually the log when the issue happens (preferrably debug level) would be very useful.
I ran into an issue recently, hope this helps someone in case it's not just a one-off with my system:
A recent software update (I can't say which one sorry, apparently the GNOME gui software updater doesn't have a history feature) broke the above system, with Pipewire failing to start (error: "spa.alsa: Could not determine card index, maybe set api.alsa.card"). I was able to fix this by changing the following line in pipewire.conf from
- Running Fedora 41, Gnome
- CamillaDSP via ALSA
- Apps outputting via Pipewire to ALSA loopback device
A recent software update (I can't say which one sorry, apparently the GNOME gui software updater doesn't have a history feature) broke the above system, with Pipewire failing to start (error: "spa.alsa: Could not determine card index, maybe set api.alsa.card"). I was able to fix this by changing the following line in pipewire.conf from
to
Thanks,Please excuse my English, I use Google Translate.
CDSP UI CPU load: 50%-60%（4 channel Load IIR wav filter）.I also tested without any filter CDSPUI CPU load 0%
Next time i return to HT, I will check the log file.
To avoid misunderstanding, I will describe the problem:
Detect delay change: REW Measure A speaker (CDSP processing), Timin Use acoustic timing reference B speaker (without CDSP processing，Not connected to sound card). The original delay is 0.00xx ms.
Take ezbeq as an example,
1. Upload beq filter, delay increases by 15-50ms (maybe around 30ms, I forgot).
2. Clean beq filter, delay also changes.
3. Service camilladsp restart, delay returns to 0.00xx ms
ps. If I don't set 10ch in, 8ch out, mixers mapping 4-channel, I won't be able to use device: hw, I can only use plughw
Last edited:
REW with CamillaDSP on a RPi5 as a USB connected output device (Gadget).
I have been running REW on a Win 11 laptop with CamillaDSP on a RPi 5 in gadget mode set up as detailed here https://github.com/mdsimon2/RPi-CamillaDSP?tab=readme-ov-file#8-enable-usb-gadget-optional . This sets up the RPi as USB capture device at 44100Hz
REW preferences > Soundcard, selecting the REW output device shows the Gadget mode twice in the selection panel, selecting "EXCL: Speakers (3-Source/Sink)" gives a higher signal level than the "Speakers (3- Source/Sink)" . I understand "EXCL" means "Exclusive Mode" and is intended to give you a 'straight signal flow' through the computer without imposing any digital signal processing from the device OS (like volume control, balance, tone settings, sample rate changes/resampling, spatial FX, etc).
REW input device of Umik-1 has to be in non exclusive mode and in Windows Settings > System > Sound you should turn Audio Enhancements off.
Windows shows the Umik-1 as "2 channels, 24 bit, 4800 Hz (Studio Quality), so I tried adding the option of 48000Hz to the RPi gadget mode as per the Gadget Mode instructions, changed the CamillaDSP Capture Sample Rate to 48000, and then in REW Preferences > Soundcard, found that setting the Sample rate to 48kHz allowed both Output and Input devices to run in Exclusive mode.
This pic shows REW Preferences > Soundcard while performing a check level with output and input set to 48kHz.
CamillaDSP will sit with "State: STALLED" until a signal is sent to CamillDSP by for instance using the "Check levels" facility in REW. CamillaDSP will then go to "State: RUNNING". However, I have found that if the CamillaDSP mixer is set to "Mute" all but two channels, CamillaDSP will remain "STALLED". Henrik, is that by design ? It would be good if CamillaDSP would run with all but one channel muted during testing with REW.
Running REW with a USB connected output device simplifies the setup for testing of CamillaDSP speaker systems.
I have been running REW on a Win 11 laptop with CamillaDSP on a RPi 5 in gadget mode set up as detailed here https://github.com/mdsimon2/RPi-CamillaDSP?tab=readme-ov-file#8-enable-usb-gadget-optional . This sets up the RPi as USB capture device at 44100Hz
REW preferences > Soundcard, selecting the REW output device shows the Gadget mode twice in the selection panel, selecting "EXCL: Speakers (3-Source/Sink)" gives a higher signal level than the "Speakers (3- Source/Sink)" . I understand "EXCL" means "Exclusive Mode" and is intended to give you a 'straight signal flow' through the computer without imposing any digital signal processing from the device OS (like volume control, balance, tone settings, sample rate changes/resampling, spatial FX, etc).
REW input device of Umik-1 has to be in non exclusive mode and in Windows Settings > System > Sound you should turn Audio Enhancements off.
Windows shows the Umik-1 as "2 channels, 24 bit, 4800 Hz (Studio Quality), so I tried adding the option of 48000Hz to the RPi gadget mode as per the Gadget Mode instructions, changed the CamillaDSP Capture Sample Rate to 48000, and then in REW Preferences > Soundcard, found that setting the Sample rate to 48kHz allowed both Output and Input devices to run in Exclusive mode.
This pic shows REW Preferences > Soundcard while performing a check level with output and input set to 48kHz.
CamillaDSP will sit with "State: STALLED" until a signal is sent to CamillDSP by for instance using the "Check levels" facility in REW. CamillaDSP will then go to "State: RUNNING". However, I have found that if the CamillaDSP mixer is set to "Mute" all but two channels, CamillaDSP will remain "STALLED". Henrik, is that by design ? It would be good if CamillaDSP would run with all but one channel muted during testing with REW.
Running REW with a USB connected output device simplifies the setup for testing of CamillaDSP speaker systems.
There is very likely a buffer underrun message. Recovering from that will take s little bit of time, which delays the playback. Do you need to use such a small chunk size?
When an underrun happens, with your config CamillaDSP has no way to adjust anything to get back to the original delay. This could be improved to make it drop samples when recovering.
It should not stay in stalled. Can you attach the config with the muting set up like this, and/or a screenshot of the mixer config in the gui?
That sound perfectly OK. IIUC your Umik USB microphone supports only 48kHz. That's why exclusive mode cannot use it at 44.1kHz which REW was switched to. Only shared mode which goes through the windows mixer and has an internal resampler and supports any samplerate on the application side. When you switched your gadget and subsequently REW to 48kHz, both devices could be used in exclusive mode.
On re-testing it works perfectly, on the 8 outputs I can mute from 1 to 7 and it goes from stalled to running each time. I must of had some other config error. Apologies for false alarm.
Some more experimentation:
This includes a couple of suggestions from @ChrisPatlach. It still shows gain with colour, but also with a number. Muting is shown crossed out with a grey background. I also added the channel labels, but did not get to how to show the inverted state yet.
.
This includes a couple of suggestions from @ChrisPatlach. It still shows gain with colour, but also with a number. Muting is shown crossed out with a grey background. I also added the channel labels, but did not get to how to show the inverted state yet.
Adding channel labels for the playback device would be fairly simple and I see how it may be useful to show for example which physical connector a signal goes to. I'll add that in the next version.
.
The current labels look good, so it will be interesting to see this next version.
