• 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

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.

Yes I resample with this recipe: -R "vX:::28:95:105:45"

It is the overall attenuation I meant rather than the lowpass filter. Looking at the squeezelite manpage, attenuation is the third field (after the second colon), and leaving it empty would apply the default attenuation of 1 dB. Maybe that is not enough for some "hot" recordings, thus the clipping you are seeing. You could test some offending audio files on the command-line. (I'm not sure what these technical considerations actually mean in terms of audible distortion.)
 
While setting up resampling in squeezelite is comparably straight forward in shairport-sync it’s not.
So I had a look at pipewire. It comes pre installed in the the raspberry os.
I did a apt install pipewire-alsa and there was a pipewire device reported by aplay -L.
Next I copied https://github.com/HEnquist/camilladsp-config/blob/master/pipewire.conf to /etc/pipewire.
Changed api.alsa.path to my loopback capture device.
wpctl status reported the device id as 31.
I could not find any information on how to access a specific pipewire node through the alsa plugin. So I just set the default with wpctl set-default 31.
Now speaker-test -D pipewire -r 44100 -F S32_LE -c 2 is playing through my camilladsp setup.

Next step is figuring out how to best do resampling in pipewire.
Any pointers?
 
It is the overall attenuation I meant rather than the lowpass filter. Looking at the squeezelite manpage, attenuation is the third field (after the second colon), and leaving it empty would apply the default attenuation of 1 dB. Maybe that is not enough for some "hot" recordings, thus the clipping you are seeing. You could test some offending audio files on the command-line. (I'm not sure what these technical considerations actually mean in terms of audible distortion.)
The input clipping I was referring to is on the UR23 interface from the CD player, which doesn't use Squeezelite. The UR23 is straight 16/44.1 PCM into CDSP.

I do see input clipping when streaming via Squeezelite from time to time too though. Squeezelite resamples to 32 bit before it outputs to CDSP, where I have the -4dB gain. Would it be better to apply greater attenuation in the Squeezelite resampling and remove the -4dB in CDSP?
 
AsyncSinc Balanced at 96KHz on a Pi4b.
Async resampler is significantly more demanding than the sync one, used e.g. in SoX. Do you need the async version to assist the rate adjust?
 
Async resampler is significantly more demanding than the sync one, used e.g. in SoX. Do you need the async version to assist the rate adjust?
Yes, good point! I use async because the CD player/UR23 has a different clock to the M4 DAC. Otherwise the clocks drift and create buffer underruns/overruns.

Is it worth using synchronous and playing around with the buffer and chunk size to see if CDSP can play a whole CD without encountering buffering issues?
 
If your capture device runs asynchronously with the playback device, and cannot have its rate adjusted (which works only for alsa loopback and usb gadget), then the async resampler is necessary.
 
playing around with the buffer and chunk size to see if CDSP can play a whole CD without encountering buffering issues?
No problem if you are lucky and the cd player runs faster than the DAC, then you just get a slowly increasing delay. If it's the other way around I wouldn't expect it to be possible.
 
Ultimately I decided against pipewire. It is too much overhead for my usecase and not suitable for the piCorePlayer.
Instead I plan to setup a physical switch to toggle between a 96k setup and a 44,1k setup.
That switch will be accompanied by other switches and buttons to start my favorite radio stations, set a sleep timer, random play …..
As all the gpio is occupied by the digi pro, I will utilize a pi zero to handle the buttons, a small display and a rotary encoder. All that will be but in a case of mahogany wood and sheetmetal to look like a vintage receiver.
 
Thanks for the input. I did indeed experiment with connecting only the required pins to an allo digione board.
This worked okay. I found it to be important to have the i2s connectors as short as possible. A 40 pin t-adapter did not work for me, introduced a lot of noise.
bj0-6InUEKdlWrYXqL6lzFup3gtS-6gs96LKka2IdqU8xw0v6_n-3YCv3dVRgtgNzZxuQHSkRo8AT5dCmvGmWZ7Z2F5nSl3Sgv-U82By1zpbq8ljTnDdHkgPey8v1rm8-w=w1280

As I already have the zero I will use it to make the setup more modular.
Your input is welcomed though, as I am considering now a wired connection to the digital pro to have it rotated by 90° for an easier mounting on the backplate.
 
image.jpg


Hey guys, I have a little macro keyboard and the rotary dials can be set to send different keystrokes every time they turn by a detent. All the keys can be configured.

I’m hoping it might be possible to plug this into the Pi that’s running CamillaDSP and set up shortcuts to adjust volume, load configs, mute, etc.

I wonder if anyone might offer some suggestions for how best approach this?
 
I assume this keyboard has an usb connector. Then it would likely identify as a hid device.
See https://www.usb.org/hid
My approach would be to write a little python script that reads keyinputs from the device and send mapped commands via pycamilladsp to cdsp.
OTOH it might be easier to connect buttons and rotary controller to the gpio.
I just started a new thread on how I am going to build a button controlled player to keep this thread uncluttered.
 
Michael, I'm attempting to upgrade a test system to CamillaDSP 3.0 - https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7897356 -

using https://github.com/mdsimon2/RPi-CamillaDSP?tab=readme-ov-file#10-upgrading-to-future-versions
The GUI and CamillaDSP binary worked fine with just changing version, however the pycamilladsp and plot do not appear to have updated from beta versions using:
sudo pip3 install git+https://github.com/HEnquist/pycamilladsp.git --break-system-packages
sudo pip3 install git+https://github.com/HEnquist/pycamilladsp-plot.git --break-system-packages
sudo service camilladsp restart

A quick search found:https://www.audiosciencereview.com/...amilladsp-tutorial.29656/page-22#post-1218123

The install command is working perfectly, please ignore.
 
Last edited:
Hi,

1.) you need the —upgrade parameter
2.) have you checked whether there is a newer version to the one you are on?

Edit:
Please ignore second line. There has been an update to pycamilladsp-plot 16 hours ago.
 
Last edited:
Next step is figuring out how to best do resampling in pipewire.
Any pointers?
Set the allowed sample rates on the capture device in pipewire, fixed sample rate to the loopback sink and then link them with pw-link.
It seems to work on my raspberry.
 
If you have a fixed setting, I.e. don’t need a session manager you can disable the alsa monitor in wireplumber and setup your devices fixed in pipewire. On my side wireplumber didn’t recognize USB devices after a reboot without resetting them.
You have to setup the link between source and sinc with a script then as pipewire cannot do this automatically without a session manager.
 
Thank you. I am still missing basic understanding of pipewire.
pw-link -o gives me:
Code:
alsa-sink:monitor_FL
alsa-sink:monitor_FR
alsa_output.platform-snd_aloop.0.analog-stereo:monitor_FL
alsa_output.platform-snd_aloop.0.analog-stereo:monitor_FR
alsa_input.platform-snd_aloop.0.analog-stereo:capture_FL
alsa_input.platform-snd_aloop.0.analog-stereo:capture_FR

Now I am guessing 'alsa_input.platform-snd_aloop.0.analog-stereo:capture_FL' is the one I want although it says alsa_input.

pw-link -i gives:
Code:
alsa-sink:playback_FL
alsa-sink:playback_FR
alsa_output.platform-snd_aloop.0.analog-stereo:playback_FL
alsa_output.platform-snd_aloop.0.analog-stereo:playback_FR
Here I am guessing I want 'alsa-sink playback_FL' since this is the one created in pipewire.conf
factory.name = api.alsa.pcm.sink
node.name = "alsa-sink"

So the link command would be
pw-link alsa_input.platform-snd_aloop.0.analog-stereo:capture_FL alsa-sink playback_FL

At least that runs without an error.


Code:
pw-link -l
alsa-sink:playback_FL
  |<- alsa_input.platform-snd_aloop.0.analog-stereo:capture_FL
alsa-sink:playback_FR
  |<- alsa_input.platform-snd_aloop.0.analog-stereo:capture_FR
alsa_input.platform-snd_aloop.0.analog-stereo:capture_FL
  |-> alsa-sink:playback_FL
alsa_input.platform-snd_aloop.0.analog-stereo:capture_FR
  |-> alsa-sink:playback_FR

Now I expect to be able to send any samplerate to pipewire and cdsp receives 96000 SL32
speaker-test -D pipewire -c 2

In camilladsp-gui I see a capture rate 96000 but no signal. (The green bars don’t move)
So somewhere along the way I must have guessed wrong.
 
Back
Top Bottom