• 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

@mdsimon2 : Thanks for adding the update commands to your tutorial. Before I give it a go: do the V2 config files need any changes made? I thought not, but recent posts on DIYaudio have me confused.

I haven't fully updated the guide for v3. It seems like v2 configurations with simple routing and no filters come over fine, but if you have filters they do not.

The process to convert to v3 isn't entirely straight forward. You need to make sure the configuration in the GUI is blank by clicking "New Blank Config" and then click "Import Config" -> "Upload new config file" -> CamillaDSP Config -> select your config and check all the boxes -> "Import". This loads the configuration in to the GUI but then you still need to save it using the disk button. After that it should show as a valid config and be labeled as version 3.

1737079352266.png


Michael
 
@mdsimon2 : Thanks for adding the update commands to your tutorial. Before I give it a go: do the V2 config files need any changes made? I thought not, but recent posts on DIYaudio have me confused.
i had to change the channel allocation from:

channel: 1

into:

channels:
- 1
 
Has anyone tried using the new Fosi VOL20 volume control knob to control volume on CamillaDSP on a Raspberry Pi via Bluetooth?
 
I haven't fully updated the guide for v3. It seems like v2 configurations with simple routing and no filters come over fine, but if you have filters they do not.

The process to convert to v3 isn't entirely straight forward. You need to make sure the configuration in the GUI is blank by clicking "New Blank Config" and then click "Import Config" -> "Upload new config file" -> CamillaDSP Config -> select your config and check all the boxes -> "Import". This loads the configuration in to the GUI but then you still need to save it using the disk button. After that it should show as a valid config and be labeled as version 3.

View attachment 421707

Michael

I used your guide, everything is working. Weird thing is I needed to install the CamillaDSP V3 twice.... Anyway all up and running with a Motu Ultralite Mk5.
Thanks @mdsimon2
1737458347009.png
 
Getting weird behaviour on output 1?? I've applied the same convolution and source channel selection filters to all channels, and output 1 is louder?
1737458819416.png


1737459284064.png


1737459111089.jpeg
 
Last edited:
Every channel apart from 1 is the same? I have rechecked.... All mixer gains are identical, all filters are identical
1737460170338.png
 
So to fix this, I had to clear the gain entries to zero. and Re-enter the gain settings.... Bug?
1737460769836.png
 
rotary encoder
Hi! Here's what you need to do (for Raspberry pi):
1. Enable the overlay in config.txt

dtoverlay=rotary-encoder
dtparam=pin_a=12,pin_b=13

where 12 is GPIO12 and 13 is GPIO13 and reboot. Check /dev/input:
root@daw3:~# ls /dev/input
by-path event0 mice

event0 - is the rotary device! You can check it using the command:
root@daw3:~# evtest /dev/input/event0
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "rotary"
Supported events:
Event type 0 (EV_SYN)
Event type 2 (EV_REL)
Event code 0 (REL_X)
...

2. Then connect rotary with scheme:


re.png



3. Now the Python program in attachment - put it in /opt/bin directory,
4. and finally, the system service encoder.service - put it in /lib/systemd/system, then

systemctl enable encoder.service
systemctl start encoder service

That's all, everything should work.
 

Attachments

  • encoder.zip
    1.1 KB · Views: 16
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.
Thanks for your input! It appears the CD player clock does indeed run faster than the DAC, so I've now configured and tested synchronous resampling a little more. At what point will the buffer level stop increasing and cause a buffer overrun? If there is a maximum buffer size, then is it configurable? If not, then will the buffer level keep increasing indefinitely? I occasionally hear an obviously audible glitch every now and then but I'm not sure what's causing it.

I'm resampling from 44.1KHz CD audio to 192KHz without a problem on a Raspberry Pi 4 with 4GB RAM (CamillaDSP v2). No clipping is reported in the GUI and the logs don't show any issues with buffer overruns or anything else for that matter. I'm currently only doing bass management using biquad filters to crossover and adding some delay. The buffer level continuously increases over time, far above the configured target_level. However, the documentation says the target_level parameter is only relevant when enable_rate_adjust is on, which it isn't. It *appears* to increase at a progressively slower rate over time, but I'm not 100% certain of this.

See the device config settings screen below.

1737770310866.png
 
At what point will the buffer level stop increasing and cause a buffer overrun? If there is a maximum buffer size, then is it configurable?
The measured buffer level will stop increasing a about 4*chunksize. Then the buffer is full, and chunks will instead start piling up in the queue between the processing thread and the playback device. That queue has s default size of 4 chunks, but can be changed by the queue limit setting.

How long does it take for the measured buffer level to increase by 1000? From that you can guess how high it will go during a full cd, and set queue limit accordingly.
 
Hi! Here's what you need to do (for Raspberry pi):
Wow this is fantastic, thank you for taking the time to provide such complete guidance. I had better order a nice rotary encoder now!
I just stumbled upon this project and thought the form factor would make a nice desktop volume controller. Stash the Pi and DAC under the desk and just have a little screen and rotary encoder up on the desktop.
dsc0945-medium.webp
 
I've finished updating the tutorial for V3, changes are summarized below.

+added section on converting configurations from V2 to V3
+converted example configurations to V3
+added bass and treble tone control filters on input channels of all example configurations
+updated flirc.py and oled.py per pycamilladsp nomenclature changes, these will need to be re-installed with V3
+pycamilladsp and pycamilladsp-plot now installed in a virtual environment, this requires updates to camillagui.service, flirc.service and oled.service
+target level changed to 3X chunk size as V3 now allows for higher target levels
+added discussion on capture and playback device labels
+eliminated references to Ubuntu Server, tutorial now only discusses on Raspberry Pi OS


Michael
 
Last edited:
+updated flirc.py and oled.py per pycamilladsp nomenclature changes, these will need to be re-installed with V3
I'm seeing two of each listed, for example flirc.py and flirc_v2.py. Both have comments that say they are for V3 but obviously neither reflect that in the filename so which do we use for CDSP V3?

+pycamilladsp and pycamilladsp-plot now installed in a virtual environment, this requires updates to camillagui.service, flirc.service and oled.service
If we currently have these installed the old/previous way (i.e. no virtual environment) do we go ahead and switch to this new method or leave as is (i.e. if we are just upgrading our current install/setup of CDSP and not setting up a system from scratch what do we do here)?
 
+eliminated references to Ubuntu Server, tutorial now only discusses on Raspberry Pi OS
Thanks for all your efforts on this.
Is there any particular reason why you chose Raspberry Pi OS? I'd like to run CDSP on piCorePlayer instead. Interested to know if you have you tried doing that before and, if so, what your experience was.
 
I'm seeing two of each listed, for example flirc.py and flirc_v2.py. Both have comments that say they are for V3 but obviously neither reflect that in the filename so which do we use for CDSP V3?
flirc.py and oled.py are the v3 versions. I just moved flirc_v2.py and oled_v2.py (and the old v2 configs) to an archive folder to make this more obvious. At the simplest level following the tutorial will install v3, so if you see flirc.py and oled.py in the instructions those are the files for v3.

If we currently have these installed the old/previous way (i.e. no virtual environment) do we go ahead and switch to this new method or leave as is (i.e. if we are just upgrading our current install/setup of CDSP and not setting up a system from scratch what do we do here)?

I'd recommend switching, see here for some more info on virtual environments -> https://henquist.github.io/pycamilladsp/install/. Short story is installing the CamillaDSP python libraries the old way could corrupt the system python installation, this is why we've needed to use "--break-system-packages" to install them. If you want to uninstall the old camilladsp python libraries you can do so by running "sudo pip3 uninstall camilladsp camilladsp-plot --break-system-packages".

I also just updated the tutorial to move the installation of the virtual environment and CamillaDSP python libraries in to the GUI step. This makes it more clear what you exactly need to run to install the virtual environment and libraries.

Is there any particular reason why you chose Raspberry Pi OS? I'd like to run CDSP on piCorePlayer instead. Interested to know if you have you tried doing that before and, if so, what your experience was.

piCorePlayer is structured differently from most linux distros, certainly very different from the debian based distros like Ubuntu and Raspberry Pi OS that I am somewhat familiar with. There is another project devoted to installing CamillaDSP on piCorePlayer, I recommend you follow that -> https://github.com/JWahle/piCoreCDSP.

For me, Raspberry OS Lite is stable, relatively light and has tons of documentation which makes it ideal. When I first started this tutorial I used Ubuntu Server because it had a newer kernel which was needed to use various MOTU interfaces, however it was always significantly slower than Raspberry Pi OS Lite. This is very obvious when using the OLED screen or observing restart times. Now that Raspberry Pi OS Lite uses a modern kernel I do not see a reason to use Ubuntu Server.

Michael
 
Last edited:
Thanks for all your efforts on this.
Is there any particular reason why you chose Raspberry Pi OS? I'd like to run CDSP on piCorePlayer instead. Interested to know if you have you tried doing that before and, if so, what your experience was.
Blew, I run Jivelite on the RPi with Camilla using RPi OS desktop and a 10" screen - see https://github.com/wirrunna/CamillaDSP-an-implemantation.
 
Back
Top Bottom