• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

RPi + CamillaDSP Tutorial

Yes, nice log. IMO there are no issues there. Did some sound issue occur during the period of the log? If so, then it may be upstream from CDSP.
Yes, distortions did occur several times during the logging period. By the way, if it matters, the stream was coming from Qobuz. Also, today I tried installing cdsp on piCorePlayer. The situation there is somewhat different: distortions only appear when capturing at 192kHz. I switched Qobuz to 96kHz, and so far I haven’t encountered any distortions. Maybe it’s somehow related to streaming specifics? I’ll try playing files from the local library to check.
 
Last edited:
There is no issue logged. IMO the distortions are produced by upstream - by the player.
 
There is no issue logged. IMO the distortions are produced by upstream - by the player.
Thank you, anyway. I'm keep gooing. What’s strange is that on Pi OS the issue is more pronounced — the capture goes through loopback, while on piCore it’s implemented differently somehow. I’ll try to figure it out. If I discover anything useful, I’ll post it here — maybe it’ll help someone.
 
I'm having a 'challenging' experience with getting an rpi5 running Moode OS and a Hifiberry dac8x confgured as 6 channels out to a 3 way active speaker set up to work. It worked yesterday with the right signal on all 6 channels, but today Moode gives me gives me a 'failed to open audio output' error msg and a 'not playing' status for 'decoded to' and 'output format' on the audio info playback page. Examining the camilladsp log file throws up 'Cannot get card index for snd-hifiberry-dac8x' and ' Failed to play on "ALSA Default" (alsa): snd_pcm_poll_descriptors_revents() failed: No such device'. The config file shows no errors. I've uploaded the CDSP log file.
My 'expertise' such as it is is more in analog audio, so I'm below schoolboy level at coding and stuck.
Any suggestions would be very gladly received.
The reason for the digital crossover is to experiment with a pair of B&W 801s, Kef 105.1's and Focal floor standers. Ive already run them with analog electronic crossovers but want to play about with the XO frequency and see what happens.
 

Attachments

IMO the card name that alsa complains as not existing is not snd_rpi_hifiberry_dac8x, but sndrpihifiberry
 
IMO the card name that alsa complains as not existing is not snd_rpi_hifiberry_dac8x, but sndrpihifiberry
Any idea why it’s looking for that card name? I’ve checked dac8x in the dt overlay box and named the dac8x as output in the devices tab in cdsp.
 
Any idea why it’s looking for that card name? I’ve checked dac8x in the dt overlay box and named the dac8x as output in the devices tab in cdsp.
And, of course, thanks for looking at this. It’s been a frustrating evening
 
IMO it's looking for that name because it's in the CDSP config. Check the config, or post it here.
 
This is the config file
 

Attachments

This is the config file
The device name does now seem correct, and the log says it
Code:
playback:
  channels: 6
  device: hw:snd-hifiberry-dac8x
  format: S32LE
  type: Alsa


Code:
2025-07-30 18:40:50.209384 [38;5;27mDEBUG[0m [src/alsadevice.rs:364] Available
Playback devices: [("hw:sndrpihifiberry,0,0", "snd_rpi_hifiberry_dac8x, , subdevice
#0"), ("hw:v....
...
ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for
snd_rpi_hifiberry_dac8x
2025-07-30 18:40:50.211726 [38;5;196mERROR[0m [src/bin.rs:293] Playback error:
ALSA function 'snd_pcm_open' failed with error 'No such device (19)'
 
Try this, it is working:

playback:
type: Alsa
channels: 8
device: "hw:sndrpihifiberry,0"
format: S32LE
 
I'm away from my system till tomorrow and then I'll try it straight away. Thanks for the suggestion!
 
I got a new desktop amp (Fosi Audio ZA3) to use RPi Zero running CamillaDSP. This amp has a trigger in 12 V. I have the required electronics to create a trigger signal from RPi 3v3 (a trigger from GPIO) 5V (raised to 12 V) pins. I also looked at the GUI and I see that it polls the backend with http requests to get the status. Intervalled polling is not an optimal solution, for a trigger. Is there a websocket to use or can it be made? I would only need the state if it's running or not.

I also noticed that I get STALLED state immediately when sound stops coming from PC. It would seem that silence_timeout in Devices does not work as intended? The timeout is critical for hysteresis control, without it it would constantly blink that amp on/off when sound comes and goes.

My version info says:
CamillaDSP 2.0.3
pyCamillaDSP 2.0.2
Backend 2.1.1

Is this still up to date? If not, is there some kind of update procedure? Automated? :)
 
I managed to upgrade all related components to newest version on 3.0 series. It seems to work nicely, but the GUI is still an interval poller and as far as I can see, no websockets available.

On Windows 11 it seems like the state of the DSP processor is highly dependant on applications that output sounds in Windows. For example Spotify will have Camilla RUNNING and PAUSED accordingly to the silence timeout, and resuming playback is instantaneous. But if I close Spotify app, it will immediately get STALLED (no matter if running or paused) and waking up from that takes a lot more time.

When no sound apps are running, if opening Windows sound settings, selecting the RPi sink and pressing Test, I will not hear all of the test sound, because waking up takes too long and it will again immediately stall. CamillaDSP should not allow stalling before silence timeout has expired or it cannot be used for 12 V triggering. It would also improve user experience if it didn't always take so long to wake up.

Does the original CamillaDSP author read this topic or should I open proposals to GitHub?
 
@Jukka: How does your Win11 pass audio to the RPi sink? Where does CDSP run?
RPi Zero 2 W, using USB OTG mode. CDSP on the RPi. I have disallowed soundcard exclusive mode in Windows for it.

For reference this is my CDSP config file after upgrading to 3. Silence_timeout is rather short, but that was for testing.
YAML:
description: 'Audiophonics DAC HAT to W4 speakers.

  Filters to optimize the W4 performance.'
devices:
  adjust_period: null
  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: 96000
  chunksize: 2048
  enable_rate_adjust: true
  multithreaded: null
  playback:
    channels: 2
    device: default:CARD=sndrpihifiberry
    format: S32LE
    type: Alsa
  queuelimit: null
  rate_measure_interval: null
  resampler: null
  samplerate: 96000
  silence_threshold: -75
  silence_timeout: 10
  stop_on_rate_change: null
  target_level: null
  volume_limit: null
  volume_ramp_time: 50
  worker_threads: null
filters:
  LPF1k:
    description: null
    parameters:
      freq: 1000
      q: 0.5
      type: Lowpass
    type: Biquad
  W4-fix1:
    description: null
    parameters:
      freq: 7500
      gain: 8
      q: 2
      type: Peaking
    type: Biquad
  W4-fix2:
    description: null
    parameters:
      freq: 13000
      gain: 6
      q: 2
      type: Peaking
    type: Biquad
  W4-fix3:
    description: null
    parameters:
      freq: 1000
      gain: 2
      q: 0.25
      type: Peaking
    type: Biquad
  W4-global-HPF1:
    description: null
    parameters:
      freq: 20
      type: HighpassFO
    type: Biquad
  W4-global-HPF2:
    description: null
    parameters:
      freq: 25
      order: 4
      type: LinkwitzRileyHighpass
    type: BiquadCombo
  W4-testing:
    description: null
    parameters:
      freq: 5000
      gain: 0
      q: 0.5
      type: Peaking
    type: Biquad
mixers:
  W4-mixer:
    channels:
      in: 2
      out: 2
    description: null
    labels: null
    mapping:
    - dest: 0
      mute: false
      sources:
      - channel: 0
        gain: -10
        inverted: false
        mute: false
        scale: dB
    - dest: 1
      mute: false
      sources:
      - channel: 1
        gain: -10
        inverted: false
        mute: false
        scale: dB
pipeline:
- bypassed: null
  description: null
  name: W4-mixer
  type: Mixer
- bypassed: null
  channels: null
  description: null
  names:
  - W4-global-HPF2
  - W4-fix1
  - W4-fix2
  - W4-fix3
  type: Filter
processors: {}
title: Audiophonics-W4
 
And how do you start CDSP? Gadget provides no data/is stuck when the host side is idle.
 
And how do you start CDSP? Gadget provides no data/is stuck when the host side is idle.
I'm not sure if I can answer that, but the RPi is powered through the USB and is always on when there is power on the PC. CDSP starts with the Linux on RPi, so my guess is that it's always on. In fact it's plugged in my laptops dock, so it's powered for most of the time. If there is anything besides that I cannot tell.
 
Does the original CamillaDSP author read this topic or should I open proposals to GitHub?
I check in here once in a while.

no websockets available.
You mean a websocket between the gui backend and the frontend? No that isn't available, and it's not something I'm planning to add. You can bypass the gui and talk to the DSP via websocket, but you will still need to poll the state.

On Windows 11 it seems like the state of the DSP processor is highly dependant on applications that output sounds in Windows. For example Spotify will have Camilla RUNNING and PAUSED accordingly to the silence timeout, and resuming playback is instantaneous. But if I close Spotify app, it will immediately get STALLED (no matter if running or paused) and waking up from that takes a lot more time.
This behavior comes from the USB gadget device. When no application uses the device, then windows closes it. This makes the capture side (where CamillaDSP is listening) immediately stop providing data. This is why it goes straight to stalled, the silence timeout doesn't matter here

When no sound apps are running, if opening Windows sound settings, selecting the RPi sink and pressing Test, I will not hear all of the test sound, because waking up takes too long and it will again immediately stall. CamillaDSP should not allow stalling before silence timeout has expired or it cannot be used for 12 V triggering. It would also improve user experience if it didn't always take so long to wake up.
How long does it take? I run my own system with usb gadget on a RPi4, and it resumes pretty much instantly.
 
Back
Top Bottom