-
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
- Thread starter mdsimon2
- Start date
I've been running it with RPi Zero 2W and a DAC hat for a few months on my work computer and it's working quite well, good stability. The GUI with its graphs is great, I love it!
I previously used RPi 4B, it gave me power related syslog errors, but I found out that my power supply was sagging and that might have caused errors in the RPi.
Observation: I use USB gadget mode input. If the device is powered up without data connection to host (those stupid power-only USB cables...), Camilla will throw errors to syslog. I suggest you improve error handling in this regard.
Feature request: it would be nice to have a FFT or other visualization in the GUI, in a new tab. Even a very rough precision bins would do. This should be optional as it obviously consumes considerably power.
I previously used RPi 4B, it gave me power related syslog errors, but I found out that my power supply was sagging and that might have caused errors in the RPi.
Observation: I use USB gadget mode input. If the device is powered up without data connection to host (those stupid power-only USB cables...), Camilla will throw errors to syslog. I suggest you improve error handling in this regard.
Feature request: it would be nice to have a FFT or other visualization in the GUI, in a new tab. Even a very rough precision bins would do. This should be optional as it obviously consumes considerably power.
OP
- Thread Starter
- #2,203
You can import partial configurations to an existing configuration file in the GUI.
Go to Files -> Import config -> Upload new config file -> CamillaDSP Config -> YAML_IZQ.yml. You can select which parts you want to upload (filters, pipeline). Make sure you click "Save to file" or " Apply and save" after importing to ensure the changes are saved.
Michel
Wirrunna
Active Member
Last edited:
Thank you for helping me so quickly, thanks to your instructions I have managed to do it without problems.
I thought that the implementation would be in a single filter for the entire file (as with the wav convolution filters), but in the end it is implemented with an equalized frequency filter.
I thought that the implementation would be in a single filter for the entire file (as with the wav convolution filters), but in the end it is implemented with an equalized frequency filter.
OP
Thanks Michael, will go for the 2gb and give a regular 3A PSU a try. I have way too many unused good USB wall warts and i really want to avoid another one if possible. I've read a bit more about the PSU in the meantime. Some things i have read, mostly in the raspberry pi forum, that can be interesting (disclaimer: I have not tried any of this):
- The recommendation from raspberry pi if the low voltage warnings show up (not sure if this is what you get) is to use a shorter or higher quality cable. The official PSU outputs 5.1V to avoid this, but regular PSU are 5.0 and can easily reach the low voltage warning limit if used with a long or low quality cable.
Another interesting point:
- Seems that with 3A the current out of the USB ports gets reduced to 0.6 instead of 1.6A. If you use a 5V that can supply more than 3A other than the official one, you can add usb_max_current_enable=1 to config.txt to force the max power setting or PSU_MAX_CURRENT=5000 to tell the power supply you are using can output 5000 mA (or whatever value). This forces the pi to rely on that and skip the PD negotiation.
The problem with battery chargers (for phones or other batteries) is that their voltage is not always precisely what is printed on the device. I got a USB power meter that plugs into the USB cord and it measures voltage and amperes. Some chargers that I use to power my Pies output something close to 4.7 V and I regularly see voltage errors in RPi log, but it works most of the time. I don't know if the Pi has or which SKUs have any power regulation and if yes how it's supposed to work. My RPi 4B usually consumes 0.4-0.6 amps when idling or working (CamillaDSP, 2 channels) depending on how many peripherals I have on GPIO and USB ports. Powering up peaks at ~0.9 and 1.0 is almost never exceeded. RPi 5 is more power hungry, I would stick to 4B in that regard, 4B has more than enough CPU power for most multichannel/HT applications. You'd need to pay attention to cooling with the 5, which is just wasted power.
One other thing. If you add an external power supply, but use Y-splitter to connect something in the same USB port, you might need a power blocker so that the two power suppliers won't fry each other. Plugging things without a Y-splitter should always be safe.
@mdsimon2 I was playing around with my RPi and testing out different configurations regarding power consumption and start up times. My Zero 2W boots up with it's current SD card in about 22 seconds according to 
So while the choosing a fast SD card is the best performance tweak, I would have hoped to have tips (from anyone who knows Linux) how to modify services so that the OS would have minimum required things it needs, in order of importance, for 1) headless operation, 2) run CamillaDSP with chosen input and output (in my case USB in and HAT out), 3) run Camilla GUI service (web interface) and 4) SSH and other system or tertiary services.
The means to accomplish would basically be tuning RPi OS Lite, disable unneeded services, reorder services so that the order of preference would be accomplished (when Camilla DSP can input and output sound, all else can come after) and maybe HW performance tuning for boot up and normal operation after that. It would seem that the Linux comes with services that have overlapping features, but my knowledge is limited about them. Even the Lite OS seems to have features that are for the GUI OS, but I cannot be sure how removing them would affect. It's quite troublesome to fix, if you don't have an SSH connection...
I have so far tried to disable as many hardware features that I don't need (Bluetooth, HDMI ports, 3.5 mm, wired NIC, etc.) with config.txt statements, but the Linux software is still quite foreign to me. I used
*) The choice to use Ubuntu Server is strange. I noticed that the Raspberry Pi OS Lite (tailored for headless) offers least amount of unnecessary features and thus best power saving and speed out-of-box. So instead of cutting branches of a server OS, I'd suggest using a lighter OS by default.
systemd-analyze. That's not bad, but I was hoping to decrease the time it takes to output sound after power on. While my attempts to decrease power consumption inevitably increases loading times, I noticed that disabling unneeded features* and reordering service start up can have significant impact on start up time without affecting the operation of the device/Camilla services. It went down to 18 sec before I accidentally disabled some important network feature So while the choosing a fast SD card is the best performance tweak, I would have hoped to have tips (from anyone who knows Linux) how to modify services so that the OS would have minimum required things it needs, in order of importance, for 1) headless operation, 2) run CamillaDSP with chosen input and output (in my case USB in and HAT out), 3) run Camilla GUI service (web interface) and 4) SSH and other system or tertiary services.
The means to accomplish would basically be tuning RPi OS Lite, disable unneeded services, reorder services so that the order of preference would be accomplished (when Camilla DSP can input and output sound, all else can come after) and maybe HW performance tuning for boot up and normal operation after that. It would seem that the Linux comes with services that have overlapping features, but my knowledge is limited about them. Even the Lite OS seems to have features that are for the GUI OS, but I cannot be sure how removing them would affect. It's quite troublesome to fix, if you don't have an SSH connection...
I have so far tried to disable as many hardware features that I don't need (Bluetooth, HDMI ports, 3.5 mm, wired NIC, etc.) with config.txt statements, but the Linux software is still quite foreign to me. I used
systemctl list-dependencies [-reverse] and systemd-analyze blame to scout for possible candidates and I made a few adjustments to services configuration files [Unit] section After= statement by adding camilladsp, but I'm unsure about their effects. The real problem is in the long dependency trees.*) The choice to use Ubuntu Server is strange. I noticed that the Raspberry Pi OS Lite (tailored for headless) offers least amount of unnecessary features and thus best power saving and speed out-of-box. So instead of cutting branches of a server OS, I'd suggest using a lighter OS by default.
OP
Hello everyone,
I'm a newbie to CamilleDSP and I have a couple of issues and questions. I use Camille DSP for DRC via the convolution WAV filters I create with REW. As you see from the plot View I use CDP in a very simple way.
1. No matter the source file's native sample rate, I always see 48Khz on my DAC so I can not change the output sample rate and I couldn't figure out how to enable the resampling function. I use GUI not the CLI and under "Devices" when I change the "samplerate" to what I want, it won't make any difference my Dac always shows 48kHz but CDP capture samplerate shows the native sample rate of the file so it resamples the output sample rate at 48kHz and I don't know why and how it is doing it. I need to be able to control that.
2.Is there a a way of switching filters automatically according to the native sample rate of the source file? (Maybe I can do this with YAML filters not WAV, or writing a script stc. I'm not sure). I think I must use the same sample rate as my filter with CDP because when I play a higher sample rate let's say 96kHz from Qobuz and use a filter at 48kHz the sound doesn't feel right. When everything is in order and at same sample rates the sound is just fantastic. I used HQPlayer in the past and I think it does that adjustment automatically at the back end on its own because I have never had this issue when I use conv. filters and reampling function on it. I don't know how this works in CDP.
3. I have seen some posts here where "Resample" is defined in the pipeline but I couldn't find it so how can I add a desired resmpale function in my pipeline flow?
I have just started to use CDP so this it so far. I'm sorry if this was explained before I tried to search the thread but couldn't find it.
I'm a newbie to CamilleDSP and I have a couple of issues and questions. I use Camille DSP for DRC via the convolution WAV filters I create with REW. As you see from the plot View I use CDP in a very simple way.
1. No matter the source file's native sample rate, I always see 48Khz on my DAC so I can not change the output sample rate and I couldn't figure out how to enable the resampling function. I use GUI not the CLI and under "Devices" when I change the "samplerate" to what I want, it won't make any difference my Dac always shows 48kHz but CDP capture samplerate shows the native sample rate of the file so it resamples the output sample rate at 48kHz and I don't know why and how it is doing it. I need to be able to control that.
2.Is there a a way of switching filters automatically according to the native sample rate of the source file? (Maybe I can do this with YAML filters not WAV, or writing a script stc. I'm not sure). I think I must use the same sample rate as my filter with CDP because when I play a higher sample rate let's say 96kHz from Qobuz and use a filter at 48kHz the sound doesn't feel right. When everything is in order and at same sample rates the sound is just fantastic. I used HQPlayer in the past and I think it does that adjustment automatically at the back end on its own because I have never had this issue when I use conv. filters and reampling function on it. I don't know how this works in CDP.
3. I have seen some posts here where "Resample" is defined in the pipeline but I couldn't find it so how can I add a desired resmpale function in my pipeline flow?
I have just started to use CDP so this it so far. I'm sorry if this was explained before I tried to search the thread but couldn't find it.
Update...
I looked into the Avaliable playback devices and I saw more options with " Amanero card with all software conversions" and when I choose this as my playback device now I can be able to resample my music. This takes care of my 1st question. I still need to understand how the resampling works with my convolution filter.
I looked into the Avaliable playback devices and I saw more options with " Amanero card with all software conversions" and when I choose this as my playback device now I can be able to resample my music. This takes care of my 1st question. I still need to understand how the resampling works with my convolution filter.
OP
- Thread Starter
- #2,214
My tutorial does not cover stdin as an input so there may be some considerations I am unfamiliar with. Before going further, I strongly suggest you read the tutorial linked in the first post of this thread as well as Henrik's documentation on the official CamillaDSP GitHub.
In general, CamillaDSP needs to be restarted every time the source sample rate changes to reflect the new sample rate. There are two projects that accomplish this, I've linked them below but do not plan on providing any support for implementing them as I do not use them in my tutorial.
github.com
github.com
If you are restarting CamillaDSP to reflect the new sample rate you need to create FIR filters for each sample rate unless you have a CamillaDSP configuration which resamples to a constant playback rate which matches the rate your FIR filter was designed at.
The other method of dealing with source sample rate changes is to have your software player resample. This is the method I use in my tutorial, and it is the simplest. In this case CamillaDSP runs at a constant capture rate which matches the output of your software player.
What software player are you using? Does it have the ability to resample to a constant sample rate?
Michael
In general, CamillaDSP needs to be restarted every time the source sample rate changes to reflect the new sample rate. There are two projects that accomplish this, I've linked them below but do not plan on providing any support for implementing them as I do not use them in my tutorial.
GitHub - scripple/alsa_cdsp: ALSA plugin for Camilla DSP
ALSA plugin for Camilla DSP. Contribute to scripple/alsa_cdsp development by creating an account on GitHub.
github.com
GitHub - marcoevang/camilladsp-setrate: Automatic sample rate switcher for CamillaDSP
Automatic sample rate switcher for CamillaDSP. Contribute to marcoevang/camilladsp-setrate development by creating an account on GitHub.
github.com
If you are restarting CamillaDSP to reflect the new sample rate you need to create FIR filters for each sample rate unless you have a CamillaDSP configuration which resamples to a constant playback rate which matches the rate your FIR filter was designed at.
The other method of dealing with source sample rate changes is to have your software player resample. This is the method I use in my tutorial, and it is the simplest. In this case CamillaDSP runs at a constant capture rate which matches the output of your software player.
What software player are you using? Does it have the ability to resample to a constant sample rate?
Michael
Thank you for your answer I'm using picore player and LMS so I will have to look into it wether if I can use a plugin to resample everything at my desired sample rate from the source.
How can I have CamillaDSP configuration which resamples to a constant playback rate which matches the rate my FIR filter was designed at? After I had set my Amanero Card with all software conversion I could actually set the output sample rate same with my FIR filter through CDSP If this fits for what you suggested I could do it but if there is another way please advice.
I will definitely read your tutorial thoroughly.
How can I have CamillaDSP configuration which resamples to a constant playback rate which matches the rate my FIR filter was designed at? After I had set my Amanero Card with all software conversion I could actually set the output sample rate same with my FIR filter through CDSP If this fits for what you suggested I could do it but if there is another way please advice.
I will definitely read your tutorial thoroughly.
OP
- Thread Starter
- #2,216
I am not very familiar with PCP but I understand it is quite a bit different from what is described in my tutorial. To be honest, my tutorial may not be very applicable to you.
This post -> https://www.audiosciencereview.com/...ds/rpi-camilladsp-tutorial.29656/post-1408743 talks through the application of the ALSA CDSP plugin (which I linked in my previous post) which will restart CamillaDSP based on sample rate changes. In order to have CamillaDSP resample to a constant sample rate you would use the $samplerate$ flag for your capture rate but set your playback rate to whatever sample rate your FIR filter is designed for and enable resampling. The end result would be PCP outputting different sample rates, CamillaDSP restarting everytime the sample rate changes BUT it would always resample to a constant rate which matches your FIR filter.
What you are trying to do is a bit advanced, but I think if you read through the post I linked above as well as the alsa_cdsp GitHub information you should be able to get it working.
Michael
This post -> https://www.audiosciencereview.com/...ds/rpi-camilladsp-tutorial.29656/post-1408743 talks through the application of the ALSA CDSP plugin (which I linked in my previous post) which will restart CamillaDSP based on sample rate changes. In order to have CamillaDSP resample to a constant sample rate you would use the $samplerate$ flag for your capture rate but set your playback rate to whatever sample rate your FIR filter is designed for and enable resampling. The end result would be PCP outputting different sample rates, CamillaDSP restarting everytime the sample rate changes BUT it would always resample to a constant rate which matches your FIR filter.
What you are trying to do is a bit advanced, but I think if you read through the post I linked above as well as the alsa_cdsp GitHub information you should be able to get it working.
Michael
Thank you Michael I appreciate it. When I set the Samplerate up in the devices tab to 48000 and resampling enabled to 48000 down in the same tab, wouldn't it be resampling everything at 48K no matter what the captured samplerate is? Because by doing that I see 48k on my DAC's screen regardless of the source sample rate. Since my defined FIR filter was generated at 48K and output set to 48K wouldn't it be doing what want it to?
OP
- Thread Starter
- #2,218
This can be a bit confusing if you are not familiar with how CamillaDSP works.
If you set your CamillaDSP capture rate as 48000 Hz, your software player will only be able to output 48000 Hz to CamillaDSP. This means there must be some resampling done prior to CamillaDSP. The resampling can either occur in your software player or in ALSA. As a default, the ALSA resampler is poor, at least it was a few years ago.
This thread documents when I learned about this a few years ago -> https://www.audiosciencereview.com/...nterface-motu-m4-phenomal-dsp-streamer.24493/. Post 34 shows the difference between squeezelite and ALSA resampling.
Michael
If you set your CamillaDSP capture rate as 48000 Hz, your software player will only be able to output 48000 Hz to CamillaDSP. This means there must be some resampling done prior to CamillaDSP. The resampling can either occur in your software player or in ALSA. As a default, the ALSA resampler is poor, at least it was a few years ago.
This thread documents when I learned about this a few years ago -> https://www.audiosciencereview.com/...nterface-motu-m4-phenomal-dsp-streamer.24493/. Post 34 shows the difference between squeezelite and ALSA resampling.
Michael
Wirrunna
Active Member
My prime source is LMS, have a look here https://github.com/wirrunna/CamillaDSP-an-implemantation
Mostmax
Member
- Joined
- Nov 22, 2018
- Messages
- 12
- Likes
- 27
MASSIVE thanks to @mdsimon2 for bringing this guide together and to the people who contributed to this thread for troubleshooting. Got it up and running in relatively little time. Squeezelite needed an uninstall/reinstall for some reason, but now it seems reliable.
The real fun has been running a Sony D-E551 Discman's optical out into CamillaDSP via a Hifime UR23.
I'm still making adjustments to the device settings for this, as I was experiencing dropouts/clicks/pops. After experimenting with chunksize, resampling settings, changing playback devices, etc., I tried copying the parameters @MCH used for a different capture device:
https://audiosciencereview.com/forum/index.php?threads/rpi-camilladsp-tutorial.29656/post-1225170
I've had the best results with similar settings:
Adding the Flirc remote for switching sources, muting, and adjusting volume was a breeze. However, if anyone has any guidance on using a Flirc remote to control Squeezelite (running Raspberry Pi OS Lite), please let me know. From what I gather, it's a matter of using Triggerhappy (thd) to trigger scripts.
Guides like this renew my continual amazement at ASR and makes the hifi hobby fun, thanks again.
The real fun has been running a Sony D-E551 Discman's optical out into CamillaDSP via a Hifime UR23.
I'm still making adjustments to the device settings for this, as I was experiencing dropouts/clicks/pops. After experimenting with chunksize, resampling settings, changing playback devices, etc., I tried copying the parameters @MCH used for a different capture device:
https://audiosciencereview.com/forum/index.php?threads/rpi-camilladsp-tutorial.29656/post-1225170
I've had the best results with similar settings:
Adding the Flirc remote for switching sources, muting, and adjusting volume was a breeze. However, if anyone has any guidance on using a Flirc remote to control Squeezelite (running Raspberry Pi OS Lite), please let me know. From what I gather, it's a matter of using Triggerhappy (thd) to trigger scripts.
Guides like this renew my continual amazement at ASR and makes the hifi hobby fun, thanks again.
