RPi + CamillaDSP Tutorial

[Dinesh V]

My Motu MK5 died. I bought another, setup the Raspberry PI5 with Raspbery OS Lite 64 bit and Camilladsp 3.0. Started with clean config files @mdsimon2 had published ultralitemk5_toslink_48c_48p.yml. The output appears to low. I have removed all of the filters, except keep the minimal highpass for tweeter and lowpass for bass, to trouble shoot. I see it in CamillaGUI as well, the input signals are stronger than output signals despite not having any gain/attentuation configured in the path. The difference is probably around 20db. My old Motu was substantially louder. I performed a factory reset on Motu, and it made no difference. Here is the current config. Please help debug this.

 

[tedtedted]

Thank you Michael. @HenrikEnquist is this something that can be changed? Intuitively, it seems to me that switching EQ with Shortcuts/Quick Config should do the same as marking the config active in the files tab as well as applying to the running DSP.

If you don't mind poking around at the camillagui source code, it's probably easy to change.

Take a look at these two files and lines:

camillagui/src/shortcuts.tsx at 43115ab85b94592cf79d84bd039a891d77ce6a57 · HEnquist/camillagui

Contribute to HEnquist/camillagui development by creating an account on GitHub.

github.com

camillagui/src/filestab.tsx at 43115ab85b94592cf79d84bd039a891d77ce6a57 · HEnquist/camillagui

Contribute to HEnquist/camillagui development by creating an account on GitHub.

github.com

 

[mdsimon2]

My Motu MK5 died. I bought another, setup the Raspberry PI5 with Raspbery OS Lite 64 bit and Camilladsp 3.0. Started with clean config files @mdsimon2 had published ultralitemk5_toslink_48c_48p.yml. The output appears to low. I have removed all of the filters, except keep the minimal highpass for tweeter and lowpass for bass, to trouble shoot. I see it in CamillaGUI as well, the input signals are stronger than output signals despite not having any gain/attentuation configured in the path. The difference is probably around 20db. My old Motu was substantially louder. I performed a factory reset on Motu, and it made no difference. Here is the current config. Please help debug this.

Check the output levels in Cuemix. My Mk5 came from the factory with 20 dB attenuation applied to all outputs.

M

Post in thread 'MOTU UltraLite-mk5 Review (Audio Interface)'

Jul 10, 2021

I am thinking of getting one of these for DAC and amplifier measurements, can anyone think of a sub-$1K ADC that would be better performing for that purpose than this?

Michael

Ended up impulse buying one of these as I figured even if it was only a small improvement over the MOTU M4 in terms of measurements the 10 channels of output + master volume control + SPDIF/TOSLINK inputs were enough to justify the purchase.

Overall pretty pleased with it despite a few quirks. I am a mac user and I first tried to use the interface without installing any additional software, in this...

• mdsimon2

• 

Michael

 

[Jukka]

I've been running it today to test my new subs and also see how the timing goes. After a little over an hour of continuous glitch free playback the bass section simply went silent. The log says buffer underrun and it never recovered on it's own.
chunksize: 128, queue limit: 1. Rate adjust enabled, target_level 128. silence_timeout: 0. multithreaded: yes. All else disabled or default.
Last "CamillaDSP" box data:

State: STALLED
Capt. samplerate: 96000
Rate adjust: 0.9985
Clipped samples: 0
Buffer level: 488
DSP load:
Message: OK

DSP load is usually under 5% with current filters on my RPi 4B.

Log:

2025-09-30 19:47:50.197504 INFO  [src/bin.rs:781] CamillaDSP version 3.0.1
2025-09-30 19:47:50.197567 INFO  [src/bin.rs:782] Running on linux, aarch64
2025-09-30 19:47:50.590125 INFO  [src/alsadevice.rs:117] PB: Starting playback from Prepared state
2025-09-30 19:47:52.037593 INFO  [src/alsadevice.rs:561] PB: device stalled
2025-09-30 19:47:52.045045 INFO  [src/alsadevice.rs:552] PB: device resumed normal operation
2025-09-30 19:47:52.048583 INFO  [src/alsadevice.rs:561] PB: device stalled
2025-09-30 19:47:52.056576 INFO  [src/alsadevice.rs:552] PB: device resumed normal operation
2025-09-30 19:55:38.485185 INFO  [src/alsadevice.rs:561] PB: device stalled
2025-09-30 19:55:38.492359 WARN  [src/alsadevice.rs:242] Prepare capture device
2025-09-30 19:55:38.493996 INFO  [src/alsadevice.rs:552] PB: device resumed normal operation
2025-09-30 19:55:38.512588 INFO  [src/alsadevice.rs:976] Capture device is stalled, processing is stalled
2025-09-30 19:55:38.512846 ERROR [src/bin.rs:314] Capture error: ALSA function 'snd_pcm_start' failed with error 'Broken pipe (32)'
2025-09-30 19:56:18.801774 WARN  [src/processing.rs:97] Failed to build thread pool, error: The global thread pool has already been initialized.
2025-09-30 19:56:19.106964 INFO  [src/alsadevice.rs:117] PB: Starting playback from Prepared state
2025-09-30 20:23:25.754462 WARN  [src/alsadevice.rs:113] PB: Prepare playback after buffer underrun
2025-09-30 20:23:25.763878 WARN  [src/alsadevice.rs:113] PB: Prepare playback after buffer underrun
2025-09-30 20:46:23.472481 WARN  [src/alsadevice.rs:165] PB: wait underrun, trying to recover. Error: ALSA function 'snd_pcm_wait' failed with error 'Broken pipe (32)'
2025-09-30 20:46:23.480304 WARN  [src/alsadevice.rs:242] Prepare capture device
2025-09-30 20:46:23.500555 INFO  [src/alsadevice.rs:976] Capture device is stalled, processing is stalled
2025-09-30 20:46:23.500761 ERROR [src/bin.rs:314] Capture error: ALSA function 'snd_pcm_start' failed with error 'Broken pipe (32)'

Is this related to the low chunk size? If so, would it have played 2 hours before halting if I used 256? Why didn't it recover and keep playing?
Or maybe it's related to continuous playback without breaks, so the stream didn't have a chance to reset and refill buffers. In my opinion situations like that should be handled somehow, not by crashing.

The actual issue is the is the fact that it didn't recover. Booting it just for that is troublesome.

 

[phofman]

Async resampling enabled?

Target level of 128 at 96k means you ask CDSP to keep 1.3ms of buffer on average, with 1.3ms chunk being added every cycle. That means a delay of 1.3ms in the timing will cause buffer underrun on the playback side.

 

[mdsimon2]

Chunk size is a good guess, but difficult to say given you are using hardware I am unfamiliar with. Important to note 128 chunk size is 1/4 of chunk size I recommend in my tutorial for 96 kHz and 1/16 of what Henrik recommends. Of course, if you increase chunk size and the issue goes away you know it is chunk size related.

For rate adjust configurations you generally want target level to be 3X chunk size. If you are truly running a synchronous setup clocked by SPDIF, 1X chunk size should be fine for target level, but I would eliminate rate adjust and resampling, you should see a roughly constant buffer level. Rate adjust configurations always have some buffer fluctuation so the larger target level gives more margin.

Michael

 

[Dinesh V]

Check the output levels in Cuemix. My Mk5 came from the factory with 20 dB attenuation applied to all outputs.

Where would that setting be? I went through all the tabs looking for that setting, could not find one. The output tab has everything at 0, rest of the tabs it is either 0db or -infinity.

 

[HenrikEnquist]

Is this related to the low chunk size? If so, would it have played 2 hours before halting if I used 256? Why didn't it recover and keep playing?

Almost certainly caused by the small chunk size. It tried to recover, but then got a broken pipe error from the Alsa layer. At that point the device has to be closed and reopened, and CamillaDSP needs to stop and reload the config to do that.

 

[mdsimon2]

Where would that setting be? I went through all the tabs looking for that setting, could not find one. The output tab has everything at 0, rest of the tabs it is either 0db or -infinity.

On the output tab check Monitoring and Output Trim.

If that looks fine, eliminate CDSP from the equation and make some voltage measurements with a multimeter. 0 dBFS should be around 8.6 V.

Michael

 

[antoinecat]

I am looking to use a Raspberry Pi 4 with a DAC hat to output an Airplay 2 stream (airplay on iOS or Mac or airfoil) in a multi-room configuration.

I am hoping use CamillaDSP as a high pass filter to output through the DAC Hat to my amplifier powering my speaker. An Airport Express is connected to my subwoofer which has an integrated low pass filter. That way I hope to crossover my system at a higher frequency rate than my current 55Hz.

Can someone point to a robust way to implement this? Would CamillaDPS on a PI do it, as in the tutorial? Is it even possible given that Airplay 2 may change rates on the fly?
I am looking to achieve this inexpensively.

 

[mdsimon2]

I am looking to use a Raspberry Pi 4 with a DAC hat to output an Airplay 2 stream (airplay on iOS or Mac or airfoil) in a multi-room configuration.

I am hoping use CamillaDSP as a high pass filter to output through the DAC Hat to my amplifier powering my speaker. An Airport Express is connected to my subwoofer which has an integrated low pass filter. That way I hope to crossover my system at a higher frequency rate than my current 55Hz.

Can someone point to a robust way to implement this? Would CamillaDPS on a PI do it, as in the tutorial? Is it even possible given that Airplay 2 may change rates on the fly?
I am looking to achieve this inexpensively.

Would the DAC HAT feed both your speaker and your subwoofer? Or just the speaker?

Michael

 

[antoinecat]

Would the DAC HAT feed both your speaker and your subwoofer? Or just the speaker?

Michael

Just the speakers. The subwoofer is connected to an airport express.

Thank you Michael.

 

[mdsimon2]

Just the speakers. The subwoofer is connected to an airport express.

Thank you Michael.

It is not a good idea to only run some channels through CamillaDSP because it has variable latency. The variable latency will mess with how your crossover sums, although it is less of an issue with lower frequency crossovers. I personally wouldn't do it.

Michael

 

[antoinecat]

Bummer.

Are you suggesting I would be better off running a DSP crossover with an 8 channel HAT (like raspiaudio or hifiberry) and feed the speakers and the subwoofer through the hat? I could bring the subwoofer closer or feed its RF transmitter.

Wouldn't the variable latency also have an impact on airplay 2 multi-room capabilities in general? Is there no way to minimise or eliminate the latency? Would a dedicated DSP HAT like hifiberry's one help?

 

[mdsimon2]

Are you suggesting I would be better off running a DSP crossover with an 8 channel HAT (like raspiaudio or hifiberry) and feed the speakers and the subwoofer through the hat? I could bring the subwoofer closer or feed its RF transmitter.

Yes, run everything through CamillaDSP, even if it is just pass through with no filters applied.

Wouldn't the variable latency also have an impact on airplay 2 multi-room capabilities in general? Is there no way to minimise or eliminate the latency? Would a dedicated DSP HAT like hifiberry's one help?

For typical multi-room setups, I don't think it will be a big deal. Latency variability should only be 1-2 ms and in a typical multi-room application you are talking about 10+ ms difference between rooms (1 ms = ~1 ft).

There is no reliable way to keep CamillaDSP latency stable. The best bet would be to never pause, start or stop CamillaDSP and it should remain stable, but it's a very finnicky solution and unreliable.

Dedicated DSP platforms should have constant latency. I know miniDSP does, not sure about the Hifiberry DSP HAT.

Michael

 

[antoinecat]

Yes, run everything through CamillaDSP, even if it is just pass through with no filters applied.

Another instance of Camilla DSP on my subwoofer playing airplay 2 would not solve the problem I imagine - since two CamillaDSP instances would not be synchronized I imagine.

Unfortunately I had just ordered a kit of the protodac, before talking to you, hoping that my idea would work, but that's obviously only 2 channels. I want(ed) the protodac to feed my speakers with a high pass filter of the 4th order at around 120hz. That leaves my subwoofer needing another source...

For typical multi-room setups, I don't think it will be a big deal. Latency variability should only be 1-2 ms and in a typical multi-room application you are talking about 10+ ms difference between rooms (1 ms = ~1 ft).

Ah. So I could possibly still play my small speaker I add as a complement in the same room and play at low volume to complement the sound. In any case good information to know.

There is no reliable way to keep CamillaDSP latency stable. The best bet would be to never pause, start or stop CamillaDSP and it should remain stable, but it's a very finnicky solution and unreliable.

As to why it still escapes me. I will still try what I have in mind and probably give up on the CamillaDSP part of it if the out of phase between speakers and subwoofer is too noticeable – or go the analogue crossover route or get a miniDSP down the line.

Thank you very much for the time answering Michael. Very much appreciated.

 

[antoinecat]

There is no reliable way to keep CamillaDSP latency stable. The best bet would be to never pause, start or stop CamillaDSP and it should remain stable, but it's a very finnicky solution and unreliable.

I am now playing with a RPI with moode and CamillaDSP over Airplay 2. I see what you are saying. In my limited testing so far, the speakers located in the same room go noticeably out of sync (one set is playing over CamillaDSP, the others via an Airport Express or Airplay 2 untouched). I monitor the discrepancy with airfoil, which allows me to adjust latency between speakers on the fly, and it seems it varies by +/-5ms or so in a listening a session. Mind you I don't really know what I am doing, but it already feels like I am chasing an elusive dream.

 

[Jukka]

If you read couple of my previous posts you can see that I too have a timing problem scenario in my setup. Currently my CDSP is set to 96 kHz samplerate, chunk size 128, queue limit 1, no silence timeout, no rate adjust, no resampler. This conf runs many hours without glitches with my gear.

Also when the system is switched on, it seems to be rather consistent with how timing sets, I have not measured any timing problems. Although I haven't measured it every time.

I think that is mainly thanks to the SPDIF and Focusrite Scarlett, which is the only device that my CDsp RPi is connected to. It's a professional audio device so it would not be too surprising if it was designed to maintain stable and predictable timing with the USB interface too (DAW interface). If you have wireless in between, I guess timing issues are baked in.

 

[Pouyoux]

first thanks to the author and the contributors for this wonderful piece of software, it's very nice to have so much capabilities and fun for free

second I've an issue with my setup, I've a shield pro 2019 connected using USB to a raspberry 4 running latest Raspberry Pi OS Lite, CamillaDSP 3.0.1 in gadget mode. It is basically working but I can't get more than 2 channels to come out of the shield, I've set the rapsberry as a 6 channels virtual card, but whatever options I'm trying on the shield, whatever software I use (Kodi, youtube) the output is only stereo while playing multichannels videos.

any hints to troubleshoot this ?

thanks

 

[phofman]

Does the shield running Android 11 actually support multichannel audio output?