• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. 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

From a CamillaDSP perspective it will report intersample overs as clipped samples if they occur as a result of CamillaDSP processing. As you are using CamillaDSP for volume control you do not need the -1 dB on all output channels, that was something I included for use with downstream DAC volume control.

Of course you can still have intersample overs upstream of CamillaDSP if you have resampling in your sources. You can likely avoid this by reducing your source volume a few dB. Important to note that intersample overs caused by your source will not be reported as clipped samples by CamillaDSP.

Michael
In my pipeline for playing CD audio I currently attenuate audio captured via the UR23 over USB to avoid intersample overs on CDs. I do this using a -4dB filter as the last step of the pipeline for each channel. Given what you say about CamillaDSP only detecting overs in its own processing, would it be better to reduce gain in the mixer input stage instead? My thinking is that the gain would then be reduced before the pipeline, and thus CamillaDSP would be aware of any intersample overs in the wave form from that point onwards.

I also wonder if this would be more efficient than using a filter.
 
In my pipeline for playing CD audio I currently attenuate audio captured via the UR23 over USB to avoid intersample overs on CDs. I do this using a -4dB filter as the last step of the pipeline for each channel. Given what you say about CamillaDSP only detecting overs in its own processing, would it be better to reduce gain in the mixer input stage instead? My thinking is that the gain would then be reduced before the pipeline, and thus CamillaDSP would be aware of any intersample overs in the wave form from that point onwards.

I also wonder if this would be more efficient than using a filter.

As CamillaDSP uses 64 bit floats, it doesn't really matter where you do the attenuation, as long as the output of your pipeline is below 0 dBFS it will not report clipping. I think there is a slight computational difference depending on whether you use a gain filter or apply gain in the mixer, but I don't think it really matters. I assume you are using CamillaDSP as volume control?

Michael
 
As CamillaDSP uses 64 bit floats, it doesn't really matter where you do the attenuation, as long as the output of your pipeline is below 0 dBFS it will not report clipping. I think there is a slight computational difference depending on whether you use a gain filter or apply gain in the mixer, but I don't think it really matters. I assume you are using CamillaDSP as volume control?

Michael
Thanks. Yes I'm currently using CamillaDSP for volume control because the MOTU M4 outputs to the Fosi V3 Mono which doesn't have volume control. Although the speakers are not very sensitive, maximum volume is still far too loud for most occasions. So, although it would be a very very rare occasion that I'd set CamillaDSP to maximum volume, I still want to configure it to avoid intersample overs at maximum volume just to be sure. I often see the input metres flash red in the GUI.
 
Thanks. Yes I'm currently using CamillaDSP for volume control because the MOTU M4 outputs to the Fosi V3 Mono which doesn't have volume control. Although the speakers are not very sensitive, maximum volume is still far too loud for most occasions. So, although it would be a very very rare occasion that I'd set CamillaDSP to maximum volume, I still want to configure it to avoid intersample overs at maximum volume just to be sure. I often see the input metres flash red in the GUI.

Is there some other processing being done before the input? Resampling perhaps?

Now that I think about it, I'm not sure what triggers clipping on the input. A certain number of samples at max level?
 
Thanks to this guide I finally just got sound out of camilladsp.
This was complicated by me starting with other guides first.
I still find it unnecessarily confusing and tedious to dig through so many, partly outdated informations.
I was led to setup alsa_cdsp, /etc/asound.conf, config_in, config_out … and a lot of other stuff that turned out to be unnecessary to get an initial setup.

Having an initial setup is now a good basis to do further modifications.
I have not read the whole thread so I don’t know whether this has already been discussed, but here are some suggestions that might help to make the first setup even easier.

1) install script
There is a nice script to install cdsp on picorePlayer. It is using alsa_cdsp though.
Similar a shell script for this guide could be created.

2) default config
Having an initial device config for the headphone device or hdmi (rpi5) with the correct capture device, samplerate etc.
would have helped to get me started.

3) speaker-test
I found the utility speaker-test a great tool for debugging my setup.
speaker-test -c 2 -D hw:Loopback,1 -l 5 -F S32_LE -r 44100
This gives easy control over output device, samplerate, and format to test device settings in cdsp.

I plan to use this together with REW RTA to see the results of my filters in my room.
Maybe a helpful addition to this great guide.

I understand that switching between samplerates requires camilladsp to be restarted and this makes setups more challenging. OTOH I pay a premium to stream high resolution audio from qobuz.

Would it work to upsample everything to 96k instead of downsampling?
Are there downside to this approach?
 
Is there some other processing being done before the input? Resampling perhaps?
I'd hope not! That's what the output is supposed to be for.
Now that I think about it, I'm not sure what triggers clipping on the input. A certain number of samples at max level?
Yes I assume it's just the recordings. I detect clipping all the time when I rip CDs and scan for replay gain.
 
I understand that switching between samplerates requires camilladsp to be restarted and this makes setups more challenging. OTOH I pay a premium to stream high resolution audio from qobuz.

Would it work to upsample everything to 96k instead of downsampling?
Are there downside to this approach?

How do you plan on upsampling? If Quboz has the ability to upsample everything to a constant 96 kHz that would be a great option. If it doesn't have that capability and you want to use CamillaDSP for resampling, you still need to restart CamillaDSP to change the capture rate, even if you are always using a constant 96 kHz playback rate. This can be accomplished via alsa_cdsp or camilladsp-setrate but is outside the scope of the tutorial.

Michael
 
How do you plan on upsampling? If Quboz has the ability to upsample everything to a constant 96 kHz that would be a great option. If it doesn't have that capability and you want to use CamillaDSP for resampling, you still need to restart CamillaDSP to change the capture rate, even if you are always using a constant 96 kHz playback rate. This can be accomplished via alsa_cdsp or camilladsp-setrate but is outside the scope of the tutorial.

Michael
The Qobuz client doesn't resample on its own. Another option is to stream Qobuz via LMS and Squeezelite then resample everything to a constant sampling rate (eg 192KHz) using Squeezelite's inbuilt Sox resampler.

 
The Qobuz client doesn't resample on its own. Another option is to stream Qobuz via LMS and Squeezelite then resample everything to a constant sampling rate (eg 192KHz) using Squeezelite's inbuilt Sox resampler.

Thank you, this is what I plan to do. My question was are there downsides to upsampling?

Any interest in the install script? My bash knowledge might just be sufficient to do that.
 
This discussion again shows the sore need for support of efficient soxr resampling at 32bit I/O samples in the alsa rate plugin. Then it would just take a simple PCM device config for CDSP to capture from, no need for complicated unreliable and latency-adding chains.
 
In my personal opinion - an installation script gives the false feeling that a project is trivial and that anyone without any knowledge can do it. A script often prevents a chance to learn what is going on compared to doing the project step-by-step. A script almost never counts with all possible options and "runners" get stuck on issues which would have been obvious and trivial to solve had they performed the steps manually. A recent example e.g. https://www.audiosciencereview.com/...en-usb-source-and-usb-dac.53750/#post-2178797
 
You are probably right. OTOH i think a lot of people just copy and paste step by step from the readme then ask for support when they missed a step or got the steps in the wrong order.
But I totally get your point.
I will write that script just for myself then.

From your previous answer I gather that one of the downsides of upsampling is (just) added latency.
This still seems to me preferable to restarting camilladsp.
 
This discussion again shows the sore need for support of efficient soxr resampling at 32bit I/O samples in the alsa rate plugin. Then it would just take a simple PCM device config for CDSP to capture from, no need for complicated unreliable and latency-adding chains.
Would be a nice quality of life improvement. To be fair, one could achieve the same thing using Pulse Audio but that is doing a bit more than just resampling.

@HenrikEnquist Have you given this more thought since 2022?
 
To be fair, one could achieve the same thing using Pulse Audio but that is doing a bit more than just resampling.
IMO that's very likely the reason why alsa plugins receive minimal effort only. Recent PipeWire is a very powerful and efficient tool, being used professionally even for embedded linux deployments. Native integration of camilladsp into a PW graph (which is already possible as CDSP supports PA API) seems like a way. Not pursued much so far, but it will come.
 
I'd hope not! That's what the output is supposed to be for.

Yes I assume it's just the recordings. I detect clipping all the time when I rip CDs and scan for replay gain.

I have squeezelite resample everything to 48kHz, so that's where destructive clipping can occur (i.e. result of resampling goes over 0 dBFS and gets truncated.)

If you are "bit perfect" at the input, then there will be no destructive clipping at that point.

Keeping the CamillaDSP volume a few dB below any gain in your subsequent filters should prevent inter-sample overs in the DAC. I'm usually between -40 dBFS and -20 dBFS for most recordings, so it's never remotely an issue.
 
I have squeezelite resample everything to 48kHz, so that's where destructive clipping can occur (i.e. result of resampling goes over 0 dBFS and gets truncated.)
When streaming via Squeezelite on my lounge system I resample everything to 192KHz, which is the maximum my DAC (MOTU M4) supports. My theory is it's better to avoid the subsequent upsampling to 176.4/192KHz by the ESS DAC chip (ES9026PRO). ie, if you're going to resample anyway, then you may as well do it all at once.

If you are "bit perfect" at the input, then there will be no destructive clipping at that point.
CD audio captured via the UR23 USB interface should be 16/44.1 bit perfect at the point that CamillaDSP processes it. Streaming audio is resampled as above.
Keeping the CamillaDSP volume a few dB below any gain in your subsequent filters should prevent inter-sample overs in the DAC. I'm usually between -40 dBFS and -20 dBFS for most recordings, so it's never remotely an issue.
That's very comfortable headroom. On some high DR recordings played on the system I'm referring to here I sometimes need to set the CamillaDSP volume to 0 dBFS to achieve what I call a good listening volume (peaks measured at about 78dB at LP of around 4m). An example is the original master of Hotel California. When watching the CDSP GUI the channel output appears to peak at around -9dBFS here. I could remove the -4dB filter but then I get clipping on lower DR recordings.
 
When streaming via Squeezelite on my lounge system I resample everything to 192KHz, which is the maximum my DAC (MOTU M4) supports. My theory is it's better to avoid the subsequent upsampling to 176.4/192KHz by the ESS DAC chip (ES9026PRO). ie, if you're going to resample anyway, then you may as well do it all at once.


CD audio captured via the UR23 USB interface should be 16/44.1 bit perfect at the point that CamillaDSP processes it. Streaming audio is resampled as above.

What kind of DSP load do you have? I have 6 channels of convolution going, so worry it would be too much for a Pi4 in a fanless case. Well, shouldn't be hard to test it, but I'm not sure it's worth what would almost certainly be an inaudible difference.

EDIT: But you are using squeezelite for resampling, right? So destructive clipping could occur there if you are not using enough attenuation in your squeezelite parameters.

That's very comfortable headroom. On some high DR recordings played on the system I'm referring to here I sometimes need to set the CamillaDSP volume to 0 dBFS to achieve what I call a good listening volume (peaks measured at about 78dB at LP of around 4m). An example is the original master of Hotel California. When watching the
CDSP GUI the channel output appears to peak at around -9dBFS here. I could remove the -4dB filter but then I get clipping on lower DR recordings.

Sounds like you need amp(s) with more gain or more sensitive speakers, particularly if the system has trouble with providing enough gain for a pop recording. I'm using two Fosi V3 stereo amps (single ended, not the V3 mono with the feedback and balanced input), which I believe have 26 dB of gain.
 
Last edited:
What kind of DSP load do you have? I have 6 channels of convolution going, so worry it would be too much for a Pi4 in a fanless case. Well, shouldn't be hard to test it, but I'm not sure it's worth what would almost certainly be an inaudible difference.
Squeezelite/Sox seems to be far more efficient at resampling than CDSP is. IIRC the system load averages below 0.5 and maximum utilisation of each core around 25%. CDSP load reported in the GUI is less than 2%. CDSP has no problem dealing with the 192KHz here, but I'm only doing crossover filtering and gain. By contrast, when resampling 44.1KHz CD audio in CDSP with the same filters I have to limit it to 96KHz to avoid buffer underruns.
EDIT: But you are using squeezelite for resampling, right? So destructive clipping could occur there if you are not using enough attenuation in your squeezelite parameters.
Yes I resample with this recipe: -R "vX:::28:95:105:45"
This specifies the very high quality profile at 192KHz, attenuates at 95% of the Nyquist frequency and allows up to 105% beyond Nyquist (so it's not too steep), and intermediate phase. I've based it on Archimago's settings:

Sounds like you need amp(s) with more gain or more sensitive speakers, particularly if the system has trouble with providing enough gain for a pop recording. I'm using two Fosi V3 stereo amps (single ended, not the V3 mono with the feedback and balanced input), which I believe have 26 dB of gain.
I'm using TRS to TRS balanced cables into the v3 Mono amps, which provides 20dB gain. I haven't tested the amps with single ended RCA at higher gain yet. The speakers are definitely undersized for the room. I originally bought them for a different room in a different house. I love the sound from them and don't have the budget to replace them, hence using the subwoofers to compensate.
 
Back
Top Bottom