Error messages below
From "wpctl status" showing alsa hw:Loopback,1 not defined to Pipewire ... there are no "Sources:" defined
Note also that the sme parameters (rate=96000, format=float32le) work in other cases
From Alsa for Loopback,0
and "pw-top" shows those parameters for the sink
From "wpctl status" showing alsa hw:Loopback,1 not defined to Pipewire ... there are no "Sources:" defined
Note also that the sme parameters (rate=96000, format=float32le) work in other cases
From Alsa for Loopback,0
and "pw-top" shows those parameters for the sink
Last edited:
I do not know what PW config you use, but the one posted in https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7933002 does tell PW to open both sides of the loopback - as discussed in subsequent posts.
Nevertheless your error does not mean the endpoint is taken by PW (the error would be EBUSY at snd_pcm_open). This looks like some mismatch of format.
Is F32P which PW reports to output to alsa-sink compatible with F32LE CDSP tries to get from the capture side of loopback? IIUC that P means planar, i.e. non-interleaved in alsa parlance, while CDSP opens the device in interleaved format. What happens if you specify the sink format in your PW config , using audio.format = "F32LE"?
Last edited:
thanks phofman .... that worked once I set the format and frequency (surprisingly S24LE in pipewire.conf actually turns up as S24LE3 on Alsa hw:Loopback,1)
phofman and Henrik
thanks for your help ... it's working much better now .... all channels are arriving into Camilladsp
I'll continue to update configs and test
👍😎
- works well in the main system (Ubuntu 24.04 cdsp 2..0.3)
- some problems in my test system (ubuntu v24.10 ... cdsp 3.0.2) but that's running in a kvm vm - see text box below. I'm not going to worry too much about that at present
phofman and Henrik
thanks for your help ... it's working much better now .... all channels are arriving into Camilladsp
I'll continue to update configs and test
👍😎
The frequency will help too since CDSP supports only one samplerate - PW will resample as needed.
Every project has its own format constants - see https://docs.pipewire.org/page_pulse_modules.html -> Common Module Options -> PCM - specifically difference between s24le and s24-32le in relation to alsa.
That does look like timing lag issue caused by running in the virtual machine. Quite common IME.
I’m experiencing an issue where the output channels keep changing, randomly routing to different DACs. I have a DIY 8-channel PCM5102 DAC (here’s a tutorial: link) and I'm using the dac8x configuration.
What was originally routed from channels 0 and 1 to DAC1 is now going to DAC3, and channels 2 and 3 are now sent to DAC1. Then, after adjusting the channel mapping in CDSP, everything seems fine for a while, but later the sound is completely off. When I check again, the channels have rerouted once more, now going to entirely different DACs.
It keeps changing randomly while I’m taking measurements, even without restarting the Raspberry Pi. I'm muting and unmuting the channels to change between the high, mid and sub driver.
---
I have another question. When measuring in REW, should I use a 44.1kHz sample rate since that’s the maximum input sample rate for CDSP? And would the results be the same regardless of whether I’m using the 44c_44, 44c_96, or 44c_192 configuration?
Or should I set REW’s sample rate to 96kHz when using the 44c_96 config and 192kHz when using the 44c_192 config?
What was originally routed from channels 0 and 1 to DAC1 is now going to DAC3, and channels 2 and 3 are now sent to DAC1. Then, after adjusting the channel mapping in CDSP, everything seems fine for a while, but later the sound is completely off. When I check again, the channels have rerouted once more, now going to entirely different DACs.
It keeps changing randomly while I’m taking measurements, even without restarting the Raspberry Pi. I'm muting and unmuting the channels to change between the high, mid and sub driver.
---
I have another question. When measuring in REW, should I use a 44.1kHz sample rate since that’s the maximum input sample rate for CDSP? And would the results be the same regardless of whether I’m using the 44c_44, 44c_96, or 44c_192 configuration?
Or should I set REW’s sample rate to 96kHz when using the 44c_96 config and 192kHz when using the 44c_192 config?
Last edited:
I tried doing speaker test, and it wouldn't let me (Playback open error: -16,Device or resource busy)
It was camillasdp using the resource:
Code:
user@pi:~ $ sudo fuser -v /dev/snd/*
USER PID ACCESS COMMAND
/dev/snd/controlC0: user 755 F.... camilladsp
/dev/snd/controlC2: user 755 F.... camilladsp
/dev/snd/pcmC0D0c: user 755 F.... camilladsp
/dev/snd/pcmC2D0p: user 755 F.... camilladspAfter stopping camilladsp speaker test worked. Not sure if that's normal or if it might be a part of the problem?
When I did the speaker test every channel was correct. After some testing it feels like camilladsp usually has the correct channels, but sometimes it just suddenly changes the channels randomly. It often happens between sweeps in REW. After it changed the channels (to the wrong configuration) I stopped camilladsp and did speaker test again, and it was correct in speaker test.
I've attached the current config where I'm working on eq the drivers. Then I'm going to add FIR filters from rephase when I've dialled the eq and delay correctly
Code:
description: null
devices:
adjust_period: 10
capture:
channels: 2
device: default:CARD=UAC2Gadget
format: S32LE
labels: null
link_mute_control: null
link_volume_control: null
stop_on_inactive: null
type: Alsa
capture_samplerate: 44100
chunksize: 256
enable_rate_adjust: true
multithreaded: null
playback:
channels: 8
device: hw:sndrpihifiberry,0,0
format: S32LE
type: Alsa
queuelimit: 4
rate_measure_interval: null
resampler: null
samplerate: 44100
silence_threshold: -100
silence_timeout: 5
stop_on_rate_change: null
target_level: 768
volume_limit: null
volume_ramp_time: null
worker_threads: null
filters:
Bass:
description: null
parameters:
freq: 85
gain: 0
q: 0.9
type: Lowshelf
type: Biquad
Treble:
description: null
parameters:
freq: 6500
gain: 0
q: 0.7
type: Highshelf
type: Biquad
delay low:
description: null
parameters:
delay: 2.1712
subsample: true
unit: ms
type: Delay
delay mid:
description: null
parameters:
delay: 0.1368
subsample: true
unit: ms
type: Delay
gain test:
description: null
parameters:
gain: -20
inverted: false
mute: false
scale: dB
type: Gain
high18_2_1:
description: null
parameters:
freq: 1680
gain: -3.4
q: 3.805
type: Peaking
type: Biquad
high18_2_10:
description: null
parameters:
freq: 14711
gain: -2.1
q: 4.998
type: Peaking
type: Biquad
high18_2_11:
description: null
parameters:
freq: 16613
gain: -1.7
q: 5
type: Peaking
type: Biquad
high18_2_12:
description: null
parameters:
freq: 18309
gain: -5.3
q: 4.999
type: Peaking
type: Biquad
high18_2_13:
description: null
parameters:
freq: 18731
gain: -5.1
q: 4.999
type: Peaking
type: Biquad
high18_2_2:
description: null
parameters:
freq: 2149
gain: -4.1
q: 1.822
type: Peaking
type: Biquad
high18_2_3:
description: null
parameters:
freq: 2617
gain: -3.7
q: 4.45
type: Peaking
type: Biquad
high18_2_4:
description: null
parameters:
freq: 3509
gain: -4.6
q: 2.159
type: Peaking
type: Biquad
high18_2_5:
description: null
parameters:
freq: 4420
gain: 1.3
q: 1.003
type: Peaking
type: Biquad
high18_2_6:
description: null
parameters:
freq: 5437
gain: -3.4
q: 4.727
type: Peaking
type: Biquad
high18_2_7:
description: null
parameters:
freq: 7230
gain: -1.9
q: 5
type: Peaking
type: Biquad
high18_2_8:
description: null
parameters:
freq: 8827
gain: -1.2
q: 5
type: Peaking
type: Biquad
high18_2_9:
description: null
parameters:
freq: 11274
gain: -2.9
q: 3.813
type: Peaking
type: Biquad
mid18_2_1:
description: null
parameters:
freq: 219
gain: -1.8
q: 4.616
type: Peaking
type: Biquad
mid18_2_2:
description: null
parameters:
freq: 292
gain: 4.3
q: 1
type: Peaking
type: Biquad
mid18_2_3:
description: null
parameters:
freq: 327
gain: -3.8
q: 4.911
type: Peaking
type: Biquad
mid18_2_4:
description: null
parameters:
freq: 386
gain: 4.4
q: 7.002
type: Peaking
type: Biquad
mid18_2_5:
description: null
parameters:
freq: 434
gain: -3.9
q: 4.918
type: Peaking
type: Biquad
mid18_2_6:
description: null
parameters:
freq: 571
gain: -3.3
q: 4.826
type: Peaking
type: Biquad
mid18_2_7:
description: null
parameters:
freq: 611
gain: -6.5
q: 4.996
type: Peaking
type: Biquad
mid18_2_8:
description: null
parameters:
freq: 724
gain: 9.1
q: 1.311
type: Peaking
type: Biquad
mid18_2_9:
description: null
parameters:
freq: 986
gain: -21.9
q: 1
type: Peaking
type: Biquad
sub18_2_1:
description: null
parameters:
freq: 56.2
gain: -1.1
q: 3.92
type: Peaking
type: Biquad
sub18_2_2:
description: null
parameters:
freq: 71.8
gain: -2.9
q: 4.667
type: Peaking
type: Biquad
sub18_2_3:
description: null
parameters:
freq: 85.5
gain: -2.7
q: 6.26
type: Peaking
type: Biquad
sub18_2_4:
description: null
parameters:
freq: 100.5
gain: -1.6
q: 11.907
type: Peaking
type: Biquad
sub18_2_6:
description: null
parameters:
freq: 122
gain: -7.3
q: 0.5
type: Peaking
type: Biquad
sub18_2_7:
description: null
parameters:
freq: 35
gain: 4
q: 3
type: Peaking
type: Biquad
mixers:
2x8:
channels:
in: 2
out: 8
description: null
labels: null
mapping:
- dest: 0
mute: false
sources:
- channel: 0
gain: 0
inverted: false
mute: false
scale: dB
- dest: 1
mute: true
sources:
- channel: 1
gain: 0
inverted: false
mute: false
scale: dB
- dest: 2
mute: true
sources:
- channel: 0
gain: 0
inverted: false
mute: false
scale: dB
- dest: 3
mute: true
sources:
- channel: 1
gain: 0
inverted: false
mute: false
scale: dB
- dest: 4
mute: true
sources:
- channel: 0
gain: 4
inverted: false
mute: false
scale: dB
- dest: 5
mute: true
sources:
- channel: 1
gain: 0
inverted: false
mute: false
scale: dB
- dest: 6
mute: true
sources:
- channel: 0
gain: 0
inverted: false
mute: false
scale: dB
- dest: 7
mute: true
sources:
- channel: 1
gain: 0
inverted: false
mute: false
scale: dB
pipeline:
- bypassed: false
description: null
name: 2x8
type: Mixer
- bypassed: true
channels:
- 4
- 5
description: null
names:
- sub18_2_1
- sub18_2_2
- sub18_2_3
- sub18_2_4
- sub18_2_6
- sub18_2_7
- delay low
type: Filter
- bypassed: true
channels:
- 2
- 3
description: null
names:
- mid18_2_1
- mid18_2_2
- mid18_2_3
- mid18_2_4
- mid18_2_5
- mid18_2_6
- mid18_2_7
- mid18_2_8
- mid18_2_9
- delay mid
type: Filter
- bypassed: true
channels:
- 0
- 1
description: null
names:
- high18_2_1
- high18_2_2
- high18_2_3
- high18_2_4
- high18_2_5
- high18_2_6
- high18_2_7
- high18_2_8
- high18_2_9
- high18_2_10
- high18_2_11
- high18_2_12
- high18_2_13
type: Filter
processors: {}
title: GadgetThat's normal, only one process at a time can use an alsa device.
Can you capture logs on debug level from a run where it changes?
Some of the filters work at a quite high frequency, up to 18 kHz. There you have frequency warping, meaning that the actual frequency ends up a bit different that the wanted one. Best to measure at the rate the dsp will run at.
What’s the best way to capture logs at the debug level? I’m fairly new to Raspberry Pi and the command line. I tried using:
journalctl -u camilladsp.service -f
but it didn’t provide any useful information.
journalctl -u camilladsp.service -f
but it didn’t provide any useful information.
It's easier to stop the systemd service and run camilladsp manually in the terminal. Then you can use "tee" to see logs in the terminal and save to a file at the same time.
camilladsp -v (and whatever options etc you normally use) 2>&1 | tee logs.txt
camilladsp -v (and whatever options etc you normally use) 2>&1 | tee logs.txt
I got some debug logs from when it initially played fine, but after a sweep, it stopped outputting sound, likely because it remapped the DACs.
When I stopped the service (sudo systemctl stop camilladsp), the GUI stopped working as well, so I couldn’t mute and unmute the channels like I normally do. It displayed “State: Offline.”
Is there a way to keep the GUI connected when running CamillaDSP manually?
I also noticed that switching to a different config and then back to the previous one restores the correct DAC channel mapping after it has been remapped (using the GUI).
When I stopped the service (sudo systemctl stop camilladsp), the GUI stopped working as well, so I couldn’t mute and unmute the channels like I normally do. It displayed “State: Offline.”
Is there a way to keep the GUI connected when running CamillaDSP manually?
I also noticed that switching to a different config and then back to the previous one restores the correct DAC channel mapping after it has been remapped (using the GUI).
I went all day without a crash. But it's gone and done it again. Anything else to try? Current config attached.
Rate adjust disabled for different soundcards? We have been discussing it here almost permanently. When you enable the rate adjust (along with async resampler), the target_level of 384 will be too low compared to the chunksize of 2048.
What sticks out to me is that the target_level is 384 with a 2048 chunksize. Here is what the readme file says about their relationship:
- target_level (optional, defaults to the chunksize value)
The value is the number of samples that should be left in the buffer of the playback device when the next chunk arrives. Only applies when enable_rate_adjust is set to true. It will take some experimentation to find the right number. If it's too small there will be buffer underruns from time to time, and making it too large might lead to a longer input-output delay than what is acceptable. Suitable values are in the range 1/2 to 1 times the chunksize. (Emphasis added).
My recommendation yesterday to turn off Resampling may have been incorrect, as noted by phoman yesterday, depending on your setup. I am using USB Gadget input or ALSA loopback, depending on what I am doing. So, for me, resampling should be turned off. But, if you are NOT using USB Gadget input or ALSA loopback, then you probably want to enable resampling. Here is what the readme says:
enable_rate_adjust (optional, defaults to false)
This enables the playback device to control the rate of the capture device, in order to avoid buffer underruns or a slowly increasing latency. This is currently supported when using an Alsa, Wasapi or CoreAudio playback device (and any capture device). Setting the rate can be done in two ways.
- Some capture devices provide a way to adjust the speed of their virtual sample clock (also called pitch adjust). This is available with the Alsa Loopback and USB Audio gadget devices on Linux, as well as BlackHole version 0.5.0 and later on macOS. When capturing from any of these devices, the adjustment can be done by tuning the virtual sample clock of the device. This avoids the need for asynchronous resampling.
- If asynchronous resampling is enabled, the adjustment can be done by tuning the resampling ratio. Then resampler must be set to one of the "Async" types. This is supported for all capture devices.
Thanks very much for this help. I've set target level to default again. I'm not sure all my changes are getting automatically saved every time.
I've tried the sampling on and off - I think I can consistently detect a slight softening of the sound with the sampling on - But I suppose there are many settings to try. Any preferences?
BTW if anyone is wondering, the dac8x is much much better than it ought to be! It's very un 'high-end-glitz' and I love it.
I've tried the sampling on and off - I think I can consistently detect a slight softening of the sound with the sampling on - But I suppose there are many settings to try. Any preferences?
BTW if anyone is wondering, the dac8x is much much better than it ought to be! It's very un 'high-end-glitz' and I love it.
Are you using CamillaGUI to make your changes, or are you editing the file with a text editor?
If using CamillaGUI, after making changes select "Apply and save" at the bottom left side of the window, in the box titled "Config".
If using a text editor, use Ctrl-s from your keyboard to save the changes.
Or in GU, check the box "Save Automatically". Is this what you have and what you question if it works?
//
//
The resampler gives a little bit of high frequency attenuation. I think I have posted some plots of that somewhere in this thread.
The higher quality presets attenuate less (but of course also use more cpu).