RPi + CamillaDSP Tutorial

[AncientMariner]

I wanted to add a "tilt" control to the Shortcuts page of the GUI, and it was really easy.

https://audiosciencereview.com/forum/index.php?threads/rpi-camilladsp-tutorial.29656/post-2055739

I found one more use for this. It annoyed me when I was trying to compare different profiles that I had to go to either the mixer or adjust a gain filter to volume match the different profiles.

So I made a shortcut that I named "Normalization" with a range of +/-2dB (I guess I could have made it only negative, but made it +/- to have the slider centered in neutral to satisfy my ocd). Obviously, care needs to be taken with the naming if using other gain filters. Hence, the choice of normalization which I think is somewhat unique.

Now I can make a small adjustment to gain from the shortcuts tab and quickly save it to the profile by hitting "apply and save".

Also, I have to say I was wrong about the usefulness of the tilt filter. I actually use that quite a lot now.

 

[HenrikEnquist]

Sometimes, I start the stream, but CamillaDSP does not receive it - the GUI volume indicator shows no incoming stream. I reboot my Raspberry Pi and then everything works.

I have seen something like this a few times, not sure if it's the same problem or not. In my case Windows doesn't manage to start playback to the usb gadget. Rebooting the pi solves it. I haven't updated anything on that system for some time so it can't be caused by some recent update. Of course it only happens just when I want to listen to something, so I haven't investigated yet.

 

[terryforsythe]

I have seen something like this a few times, not sure if it's the same problem or not. In my case Windows doesn't manage to start playback to the usb gadget. Rebooting the pi solves it. I haven't updated anything on that system for some time so it can't be caused by some recent update. Of course it only happens just when I want to listen to something, so I haven't investigated yet.

Thank you for the input! This morning it is working fine. I checked my logs and the apt-daily-upgrade.service seems to have run overnight. I also forgot to mention that I have Timeshift that runs automatically, but it also ran overnight. Nonetheless, this morning I had no issues.

I did discover this in the logs from yesterday:

Sep 21 15:30:19 dspserver kernel: xhci-hcd xhci-hcd.0: WARN: buffer overrun event for slot 1 ep 2 on endpoint

Perhaps that is due to the buffer (MAX_PAYLOAD_SIZE) setting in camilladsp-setrate. I left the buffer setting as the default value the last time I upgraded. I am going to increase it, and then check the logs again later today.

 

[cobby]

CamillaDSP isnt really the easiest software to handle and install, spend a few hours, got quite far but i gave up for now.
not using a raspi, am using a x86 minipc with ubuntu and its a pita tbh, managed to overcome some problems but its a lot one needs to care for, i might simply give up and try easyeffects or even windows with apo, seems to be more my league.

 

[mdsimon2]

CamillaDSP isnt really the easiest software to handle and install, spend a few hours, got quite far but i gave up for now.
not using a raspi, am using a x86 minipc with ubuntu and its a pita tbh, managed to overcome some problems but its a lot one needs to care for, i might simply give up and try easyeffects or even windows with apo, seems to be more my league.

Anything in particular you are struggling with? This thread is devoted to RPi applications but I have installed CamillaDSP on a HP t630 running Ubuntu Server. Install is pretty similar with a few exceptions.

1) Add user to the audio group using "sudo usermod -a -G audio username", replacing username with your username.

2) The default amd64 binary assumes pulse audio is installed. If you are using Ubuntu Server pulse audio will not be present, as a result I compile my own camilladsp binary. Brief steps are shown below.

Install rust via rustup.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Reboot.

sudo reboot now

Install dependencies.

sudo apt install pkg-config libasound2-dev

Download CamillaDSP source.

git clone https://github.com/HEnquist/camilladsp ~/camilladsp/src

Change directory.

cd ~/camilladsp/src

Compile CamillaDSP.

RUSTFLAGS='-C target-cpu=native' cargo build --release

Move compiled binary to /usr/local/bin/.

sudo cp ~/camilladsp/src/target/release/camilladsp /usr/local/bin/

Michael

 

[cobby]

awesome answer, "sudo usermod -a -G audio username", i was missing for sure.
had it running halfway, saw the GUI in the browser, but the devices config never worked for me so far.
my install had been a clusterfuck in the end, i gave up on camilladsp and tested jamesdsp afterwards which was a easy install but i have performance problems i might can solve by using a real time kernel but prob going to try easy effects next and someday again camilla when i see the benefits.
Camilla is for sure easy to setup for raspis/arm with the great scripts offered here, but for x86 its a bit, hm, lets say not for the beginner to average user.

 

[Jukka]

Yes this would be interesting and easy to check with alsactl. I don't plan to let Camilladsp write to the gadget volume control, but it could be of interest for external scripts.

When I got time I will try to add a rotary encoder for volume control and mute, and maybe some other functions.
- I think I saw instructions to call an API on the CamillaDSP. Websockets is one option, was there other ways when running local Linux scripts/apps?
- If I adjust volume through websockets, I would assume it reflects the change through UAC all the way to host PC, if supported in UAC? If not, I think it would be better if Windows volume slider could not control the Camilla volume to avoid confusion. Same with mute.

PS. I'm a professional developer. My main expertise is in dotnet and I'm reluctant to learn python, because I feel C# would be superior development language for larger than hello-world projects. I've successfully tested LEDs, rotary encoder and a small OLED display by controlling with dotnet code. There was no dotnet implementation of the displays specific chip driver, but I created one with help of ChatGPT, but there are still a couple of adjustments to be made. When the device drivers are working, any logic should be easy from there.

 

[HenrikEnquist]

- I think I saw instructions to call an API on the CamillaDSP. Websockets is one option, was there other ways when running local Linux scripts/apps?

The websocket interface is the way to talk to the camilladsp process. Most people use the pycamilladsp library to do that from python, but you can use pretty much any language you want. You just need to be able to send and receive JSON over a standard websocket connection. I'm not aware of anyone using C# but I can't imagine there would be any problems.

If I adjust volume through websockets, I would assume it reflects the change through UAC all the way to host PC, if supported in UAC? If not, I think it would be better if Windows volume slider could not control the Camilla volume to avoid confusion. Same with mute.

I just tried it with amixer. Changing "PCM Capture Volume" of the gadget moves the Windows volume slider. I have thought a little about it and it should be reasonably straightforward to transfer volume changes from websocket to the usb host.

 

[AncientMariner]

Is there a way to get setrate working on ALSA Loopback? The reason for asking is because I am interested only in 2nd feature of setrate: To reload a config file after my DAC (KEF LSX II speakers) wakes up. I run everything at 44.1kHz and the Pi as a streamer, so I don't need setrate to do any actual rate changes.

 

[phofman]

To reload a config file after my DAC (KEF LSX II speakers) wakes up.

I do not know what happens if the DAC falls asleep, but if it disappears from the bus and re-appears at wake-up, CDSP could exit when the DAC disappears and a simple udev rule could start CDSP with the fixed config.

 

[AncientMariner]

I do not know what happens if the DAC falls asleep, but if it disappears from the bus and re-appears at wake-up, CDSP could exit when the DAC disappears and a simple udev rule could start CDSP with the fixed config.

If the DAC has fallen asleep, and you try to play to it, then CSDP goes inactive due to failing to find the hardware. Pressing "Apply to DSP" will put CDSP back running, and is (in my case at least) sufficient trigger to wake the DAC. CDSP will fail again. A second press on "Apply to DSP" will now get CDSP running as the DAC has meanwhile connected. Another way is to switch profiles from the shortcuts tab, as this automatically applies a new profile to CDSP. So basically it accomplishes the same.

To avoid having to open CDSP in a webbrowser all the time, my current work-around from this is a FLIRC switching profiles a couple of time with a remote until the music starts playing. This works fine actually, but it would be more elegant if setrate could wake the DAC up for me.

 

[phofman]

Those are symptoms and some workarounds which happen to wake the device up. But I wonder what actually happens technically and how the host wakes the speakers up.

Are the sleeping speakers still listed in lsusb?

If so, are the sleeping speakers listed in aplay -l?

If so, do they wake up if you try to play something to them, e.g. with aplay?

Eventually the sleeping mode could be set to Never as described in the speakers manual https://assets.kef.com/product-support/lsx-2/LSX_II_Product_Manual_EN_v9.pdf .

 

[AncientMariner]

Those are symptoms and some workarounds which happen to wake the device up. But I wonder what actually happens technically and how the host wakes the speakers up.

Are the sleeping speakers still listed in lsusb?

If so, are the sleeping speakers listed in aplay -l?

Yes to both questions. The screenshots are from before starting streaming music to CDSP and with the speakers still asleep.

From fiddling with all this, I figured this is the difference between "ECO power mode", 20 min inactivity power off, and non-ECO 30 min power off (besides 10 mins). If it's in ECO, it will disappear from the list in aplay -l. This is also consistent with the manual which says ECO mode will not allow wake-up on USB. So I suppose it keeps a line open to at least present itself. Note: I used 30 mins power-off for the reason the manual said to do so the entire time.

If so, do they wake up if you try to play something to them, e.g. with aplay?

Yes, same behavior. I have to play the file once and wait for aplay to fail (LSX II are just called "II" in aplay -l):

kef@kef:[B]~ $[/B] aplay -D hw:II,0 /media/usb/pinknoise16.wav -f S16_LE -c2 -r44100
Playing WAVE '/media/usb/pinknoise16.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
aplay: pcm_write:2127: write error: No such device

It takes a second or two before it fails in the first attempt. This is consistent with CDSP also seems to play for a little while before failing (the output VU meters light up green for maybe a second). So I suppose some signal is sent over USB that is sufficient to wake up the speaker.

(Thank you for the 2 hour homework assignment, I learned to mount a USB stick and play a file ).

Eventually the sleeping mode could be set to Never as described in the speakers manual https://assets.kef.com/product-support/lsx-2/LSX_II_Product_Manual_EN_v9.pdf .

Leaving them permanently on would cost me an extra 150-200 Euro-Dollars per year. Just having the speakers in standby plus a Pi running permanently already cost around 40 to 50 Euro-Dollars. This is the unfortunate reality of living in Europe, and I would rather spend the money on something more sensible. The power consumption aside, KEF recommends to turn the speakers off to extend longevity.

If I turn the speakers on in USB mode prior to starting the stream (and ensuring CDSP is in "paused" state), I still need to apply the profile. Only they will play immediately with a single apply instead of 2 presses. This is not really an advantage, as I need to turn on the speakers in the KEF app, so it ends up being more complicated than just switching profiles twice.

 

[Glennart]

I have been looking for ways to add digital audio inputs to my RPi4 running CamillaDSP and have some questions.

• Does it matter if you convert the digital audio signal from coaxial to optical (or vice versa)? And with matter I mean - does it add any latency or can it alter the signal in any way?
  
  If the hardware is of importance, this is the device I bought for the purpose [ https://www.amazon.se/dp/B08MPRXXG7 ]. The idea is to use this to convert coaxial to optical and then use the Hifime UR23 to convert the optical to USB. But I'd rather do it in one step...
  
  
• As I understand it the best/cheapest option for optical input is to use a Hifime UR23 SPDIF Optical to USB converter [ https://hifimediy.com/product/hifime-ur23-spdif-optical-to-usb-converter ], but I cannot find any good option for coaxial digital audio.
  
  I found this DIY project [ https://github.com/elehobica/pico_spdif_rx ], but would rather buy something than build it myself (mostly since I'd like it to look good and this is the main problem with soldering your own converter ).
  
  So, the question is: Are there any coaxial alternatives to the Hifime UR23?
  
  
• I would also like to know if it is possible to use several digital inputs in CamillaDSP? If the answer is yes, is it possible to automatically detect which one to use or do you need to manually switch between the inputs (i.e. physically switch between the input signals or choosing inputs in the CamillaDSP application)?
  
  
  What I am trying to achieve
  • Connect my Sonos Port (using coaxial digital output) to the RPi running CamillaDSP without adding any AD/DA conversions.
    
    I have my LP record player connected to the Sonos Port analog input. To be able to add room correction I need to do some AD/DA conversion and I guess the Port has a reasonably good chip for this.
    
    
  • Connect my CD-player using optical digital output to the RPi running CamillaDSP (can be done with Hifime UR23).
    
    
  • Add room correction in CamillaDSP.
    
    
  • Output the results to miniDSP 2x4HD in digital format (perhaps USB will be best/easiest?) and do some final phase correction using all-pass filters within the miniDSP.

Any suggestions on how to optimize this (within a reasonable budget) are welcome

Edit: This might be an option as well: https://www.aliexpress.com/item/1005004018973544.html - but I'm not sure if the RPi4 supports i2s audio input or where to connect it...

 

[rthorntn]

I would like to suggest ASRC boards with AK4137 available on AliExpress, which allow you to standardize different sample rates from the source

Thanks, these look really cool and are within my budget, I have an RPi5 with DAC8X HAT and I want to take in SPDIF that has had ASRC performed before handing it to the RPi5, so would I just add one of the nvarcher mini SA9227 I2S USB sound cards available here?

Also, the AK4137 boards being used with an "I2S input to SPDIF optical output board" is mentioned, does anyone have a link for a suitable one?

I believe my DAC8X's four DAC's use all four of the PI5 I2S channels, so I need to use USB? [reading a bit more on this maybe the AK4137 ASRC could work over I2S to an RPi5/DAC8X if it can function as a slave, not really sure].

 

[Davide]

Thanks, these look really cool and are within my budget, I have an RPi5 with DAC8X HAT and I want to take in SPDIF that has had ASRC performed before handing it to the RPi5, so would I just add one of the nvarcher mini SA9227 I2S USB sound cards available here?

Also, the AK4137 boards being used with an "I2S input to SPDIF optical output board" is mentioned, does anyone have a link for a suitable one?

I believe my DAC8X's four DAC's use all four of the PI5 I2S channels, so I need to use USB? [reading a bit more on this maybe the AK4137 ASRC could work over I2S to an RPi5/DAC8X if it can function as a slave, not really sure].

The AK4137 board I suggested takes SPDIF in (any sample rate), converts it to the chosen sample rate and output I2S in the chosen format (according to I2S standard).
How to interface it to the RPI I don't know honestly.
I use a card that converts I2S back to SPDIF.

 

[rthorntn]

I use a card that converts I2S back to SPDIF

Thanks, which one?

 

[Davide]

Thanks, which one?

https://a.aliexpress.com/_EuleEUt

This works fine. Others that I have tried unfortunately no.

 

[terryforsythe]

Does it matter if you convert the digital audio signal from coaxial to optical (or vice versa)? And with matter I mean - does it add any latency or can it alter the signal in any way?

Generally speaking, it doesn't matter. Bits are bits. Coaxial may have less jitter than TosLink, depending on how well the TosLink is implemented, but I have yet to hear an implementation where I can hear the difference.

So, the question is: Are there any coaxial alternatives to the Hifime UR23?

Yes.

HiFiBerry Digi+ I/O | HiFiBerry

It has many limitations, though. See this page for details:

Comparison of HiFiBerry cards for audio recording | HiFiBerry

miniDSP makes the MCHStreamer series. I have the MCHStreamer kit, but don't recommend it. Recently I have been having issues with the input, and miniDSP's support is not very good.

I would also like to know if it is possible to use several digital inputs in CamillaDSP? If the answer is yes, is it possible to automatically detect which one to use or do you need to manually switch between the inputs (i.e. physically switch between the input signals or choosing inputs in the CamillaDSP application)?

I would look for a SPDIF coaxial switcher. I have one for TosLink that works well.

 

[mdsimon2]

I have been looking for ways to add digital audio inputs to my RPi4 running CamillaDSP and have some questions.

• Does it matter if you convert the digital audio signal from coaxial to optical (or vice versa)? And with matter I mean - does it add any latency or can it alter the signal in any way?
  
  If the hardware is of importance, this is the device I bought for the purpose [ https://www.amazon.se/dp/B08MPRXXG7 ]. The idea is to use this to convert coaxial to optical and then use the Hifime UR23 to convert the optical to USB. But I'd rather do it in one step...
  
  
• As I understand it the best/cheapest option for optical input is to use a Hifime UR23 SPDIF Optical to USB converter [ https://hifimediy.com/product/hifime-ur23-spdif-optical-to-usb-converter ], but I cannot find any good option for coaxial digital audio.
  
  I found this DIY project [ https://github.com/elehobica/pico_spdif_rx ], but would rather buy something than build it myself (mostly since I'd like it to look good and this is the main problem with soldering your own converter ).
  
  So, the question is: Are there any coaxial alternatives to the Hifime UR23?
  
  
• I would also like to know if it is possible to use several digital inputs in CamillaDSP? If the answer is yes, is it possible to automatically detect which one to use or do you need to manually switch between the inputs (i.e. physically switch between the input signals or choosing inputs in the CamillaDSP application)?
  
  
  What I am trying to achieve
  • Connect my Sonos Port (using coaxial digital output) to the RPi running CamillaDSP without adding any AD/DA conversions.
    
    I have my LP record player connected to the Sonos Port analog input. To be able to add room correction I need to do some AD/DA conversion and I guess the Port has a reasonably good chip for this.
    
    
  • Connect my CD-player using optical digital output to the RPi running CamillaDSP (can be done with Hifime UR23).
    
    
  • Add room correction in CamillaDSP.
    
    
  • Output the results to miniDSP 2x4HD in digital format (perhaps USB will be best/easiest?) and do some final phase correction using all-pass filters within the miniDSP.

Any suggestions on how to optimize this (within a reasonable budget) are welcome

Edit: This might be an option as well: https://www.aliexpress.com/item/1005004018973544.html - but I'm not sure if the RPi4 supports i2s audio input or where to connect it...

Does the Sonos Port output variable sample rate data or is the sample rate constant?

If sample rates are constant, an automatic SPDIF switcher seems like a good option -> https://www.tindie.com/products/beni_skate/automatic-spdif-opticalrca-audio-switch/. Although, there still may be issues with the UR23 or other SPDIF input devices as they don't always handle lack of data gracefully (for example when you switch inputs) which may cause CamillaDSP to stall out.

Using an automatic SPDIF switcher with the 2X4HD as the CamillaDSP capture device is a foolproof option. The ASRC in the 2X4HD will easily handle any sample rate changes. Only downside is the need for a new DAC. Also, I don't see any reason to do phase correction in CamillaDSP as it has extremely limited FIR capability, I would do it all in CamillaDSP.

Michael