RPi4 + CamillaDSP Tutorial

[itsikhefez]

I am going through this tutorial for the first time, thanks so much !

My current stack is Benchmark DAC3/LA4/AHB2, using piCorePlayer for streaming and 2 analog sources, but obviously no DSP capabilities and looking to implement DRC.
I have a Motu M4 on hand that I use for other things so trying this approach with that first, but if all works out, looking for a higher end unit.

Curious if the RME Fireface UCX-II is a good option for this? (aside from needing to create configs on my own).
Would that device support 2 analog inputs + squeezelite? If so, would I be able to then get rid of the DAC3/LA4 and use the UCX-II directly with the AHB2?

 

[mdsimon2]

I assume you are looking for more than two output channels?

UCX II has a class compliant mode and seems to support linux so it should be OK.

An issue with multichannel interfaces is volume control. You can certainly use CamillaDSP volume control, but just skimming through the manual it does not look like the UCX II knob can control volume of multiple output channels (looks like it only does ch 1/2).

You can use the UCX II with two stereo analog inputs and squeezelite. You could do this by switching CamillaDSP configurations from using an ALSA loopback as input (for squeezelite) and UCX II for analog input. Depending on your inputs you could either have one analog input configuration that captures both sources or you could have two separate analog input configurations.

Michael

 

[Nisse10000]

Anyone else having problem with Shairsync with the latest updates? With V2.0.1 and updated ubuntu 22.04 I get:

0.003791695 "rtsp.c:2897" unable to listen on IPv4 port 6000. The error is: "Address already in use".
0.000158667 "rtsp.c:2897" unable to listen on IPv6 port 6000. The error is: "Address already in use".

I've tried a number of different ports and did re-install everything to so if it helped withoput success.

 

[itsikhefez]

I assume you are looking for more than two output channels?

UCX II has a class compliant mode and seems to support linux so it should be OK.

An issue with multichannel interfaces is volume control. You can certainly use CamillaDSP volume control, but just skimming through the manual it does not look like the UCX II knob can control volume of multiple output channels (looks like it only does ch 1/2).

You can use the UCX II with two stereo analog inputs and squeezelite. You could do this by switching CamillaDSP configurations from using an ALSA loopback as input (for squeezelite) and UCX II for analog input. Depending on your inputs you could either have one analog input configuration that captures both sources or you could have two separate analog input configurations.

Michael

Thanks so much for the quick reply and confirming the UCX-II (and similar interfaces) can support both analog and streaming with the switch of configs.
I currently do only have 2 channel floorstanding speakers, but have a subwoofer and would be eventually interested to integrate it.
With the sub as an additional output channel I would want its volume to track with the other two channels, so that's a good point that you raised about the UCX-II volume.

A nice feature could be to be able to scroll through inputs with the remote (basically change configs from the remote)

 

[Yems]

There are new drivers and a firmware update available for the UltraLite-mk5. I can't find any information (other than 828 support) or changelog on what might have changed. Has anyone updated yet?

Yems

 

[mdsimon2]

Anyone else having problem with Shairsync with the latest updates? With V2.0.1 and updated ubuntu 22.04 I get:

0.003791695 "rtsp.c:2897" unable to listen on IPv4 port 6000. The error is: "Address already in use".
0.000158667 "rtsp.c:2897" unable to listen on IPv6 port 6000. The error is: "Address already in use".

I've tried a number of different ports and did re-install everything to so if it helped withoput success.

V2.0.1 switched the GUI port back to 5000 which could cause issues as that is the default shairport-sync port. However, it looks like you changed the shairport-sync port to 6000 which should solve the issue. Can you try running sudo lsof -i -P -n and post the results? That will tell you how your ports are being used.

For reference, V2.0.1 and Ubuntu 22.04 works fine for me with shairport-sync set to port 6000.

Michael

 

[mdsimon2]

There are new drivers and a firmware update available for the UltraLite-mk5. I can't find any information (other than 828 support) or changelog on what might have changed. Has anyone updated yet?

Yems

I've been using nginx to remotely access an UL Mk5 connected to a RPi for some time now (see here for more details -> #611 ) and this update doesn't change that.

Michael

 

[mdsimon2]

Thanks so much for the quick reply and confirming the UCX-II (and similar interfaces) can support both analog and streaming with the switch of configs.
I currently do only have 2 channel floorstanding speakers, but have a subwoofer and would be eventually interested to integrate it.
With the sub as an additional output channel I would want its volume to track with the other two channels, so that's a good point that you raised about the UCX-II volume.

A nice feature could be to be able to scroll through inputs with the remote (basically change configs from the remote)

This tutorial describes how to use an IR receiver and remote to change configurations. The CamillaDSP compact view is also a good way to easily change configurations from say your phone.

Just my 2 cents, but I wouldn't use CamillaDSP volume control without some sort of non computer volume indication. The display described in this tutorial is a nice way to get that volume indication and also has the advantage of being able to display your active configuration.

Another potential alternative to changing configurations is using the WaveInput LMS plugin with a separate ADC. You could digitize your analog sources with the ADC and send them via LMS to squeezelite with this plugin. You would never need to change CamillaDSP configurations and your capture device would always be an ALSA loopback.

Michael

 

[Nisse10000]

V2.0.1 switched the GUI port back to 5000 which could cause issues as that is the default shairport-sync port. However, it looks like you changed the shairport-sync port to 6000 which should solve the issue. Can you try running sudo lsof -i -P -n and post the results? That will tell you how your ports are being used.

For reference, V2.0.1 and Ubuntu 22.04 works fine for me with shairport-sync set to port 6000.

Michael

Thanks for the feedback. I had the same problem before and after the fresh install so I assumed it was the same. Now I get correct port assignment with the reinstall.

I must be some something with the output setting even if I havn't figured out what. One thing that puzzle me is that in your guide you write that "hw:Loopback,1" should be used. When I run shariport-sync -h it lists "hw:Loopback" as the available device. In my previous install I had to use "hw:Loopback" to get it to work. Does Alsa pick the firt device if it is omitted?

I'm send audio out through HDMI and in previous install I finally got it working after lots opf fiddlling and settled even though I didn't really understand how I got it working.

 

[mdsimon2]

Thanks for the feedback. I had the same problem before and after the fresh install so I assumed it was the same. Now I get correct port assignment with the reinstall.

I must be some something with the output setting even if I havn't figured out what. One thing that puzzle me is that in your guide you write that "hw:Loopback,1" should be used. When I run shariport-sync -h it lists "hw:Loopback" as the available device. In my previous install I had to use "hw:Loopback" to get it to work. Does Alsa pick the firt device if it is omitted?

I'm send audio out through HDMI and in previous install I finally got it working after lots opf fiddlling and settled even though I didn't really understand how I got it working.

It is probably a good guess that if you specify hw:Loopback it will use the 0 device but I am not sure. With the ALSA loopback, you can use either device for your CamillaDSP capture device, you just need to use the opposite one in your player. So if you use hw:Loopback,0 in shairport-sync, you need to use hw:Loopback,1 for your capture device in CamillaDSP.

Michael

 

[Nisse10000]

It is probably a good guess that if you specify hw:Loopback it will use the 0 device but I am not sure. With the ALSA loopback, you can use either device for your CamillaDSP capture device, you just need to use the opposite one in your player. So if you use hw:Loopback,0 in shairport-sync, you need to use hw:Loopback,1 for your capture device in CamillaDSP.

Michael

Thank you for your support! I went through the config again and it turned out that I used loopback instead of Loopback. Now it is working!

 

[Rednaxela]

If you don't need GPIO (display) or gadget mode I probably wouldn't go with a RPi but rather an older mac mini (2012 or 2014) or a thin client PC running Linux. I run CamillaDSP on a 2012 mac mini and it does great and has nice I/O options (FW400, FW800, TOSLINK in, TOSLINK out).

Maybe a bit off topic but this caught my eye the other day.

It could be a very elegant hardware option for something I have been thinking about recently - to create a CamillaDSP based replacement for the Behringer DEQ2496 that I now use fully digitally (optical in/out) between my TV and volume controlled DAC.

I love the idea of having something as versatile and powerful as CamillaDSP, but there are a couple of things about the Behringer I would not like to give up, which are

• boot time in the order of seconds, to avoid wanting to have it always on
• stability in terms of glitch free operation for hours on end, and
• automatic multiple input sample rate support.

For the latter, camilladsp-setrate seems a very promising solution, even though I realize I might only need it in the future.

Do you know how close one would be able to get with a Mac Mini 2012 or 2014?

 

[mdsimon2]

Boot time is seconds, but probably more like 45 seconds than 5 seconds. Just tried a few reboots:

mac mini 2012 (catalina 10.15.7): 38 seconds
mac mini 2014 (monterey 12.7.2): 43 seconds
rpi4 (ubuntu server 22.04): 43 seconds
HP t630 (ubuntu server 22.04): 48 seconds

That being said I don't reboot these systems, especially the rpi4. Which is also an answer to the stability question. I've been running a rpi4 with camillaDSP on my main system for over 2 years now. I've never experienced a glitch and I never restart other than when needed for software upgrades. It has run for several months on end without issue. Prior to this I used miniDSP systems (miniSHARC based) and would occasionally need to power cycle after switching between configurations.

The biggest issue with CamillaDSP when using an optical input will be sample rate handling. The macs are potentially an interesting option as core audio seems to recognize sample rate changes over optical, however you will still need some way to restart CamillaDSP with the new sample rate. camilladsp-set rate only works with ALSA and the USB gadget, so won't be a turnkey solution.

I played around with a TOSLINK I/O configuration on the mac mini 2012 and I think a solution could be developed pretty easily. CamillaDSP will crash if the input sample rate is changed as core audio changes the sample rate to match the new input. However, the listdevices script (https://github.com/HEnquist/cpal-listdevices) is able to correctly identify the sample rate change. If you could run the listdevices script (or something similar) every time prior to a CamillaDSP restart and then have another script change the CamillaDSP configuration file to match the currently detected input sample rate I think that would do it.

Personally, I find it easiest to deal with sample rate changes by either restricting the sample rate at the source or using an ASRC.

Michael

 

[MCH]

I think a hat with one or various spdif inputs and a ASRC chip all working in hardware mode, maybe with a remote or signal sensing, is feasible and relatively easy. I might give it a try when i have some time. The big question is how smooth these ASRC will work (i am considering SRC4192) in terms of pops or stuff like that when changing rates. That would make it unusable for me.

 

[mdsimon2]

I used an OpenDRC-DI which is a DIGI-FP (SRC4382) + miniSHARC and it was great with changing sample rates, no pops or weird behavior.

Would love to see an ASRC HAT!

Michael

 

[Rednaxela]

Boot time is seconds, but probably more like 45 seconds than 5 seconds. Just tried a few reboots:

mac mini 2012 (catalina 10.15.7): 38 seconds
mac mini 2014 (monterey 12.7.2): 43 seconds
rpi4 (ubuntu server 22.04): 43 seconds
HP t630 (ubuntu server 22.04): 48 seconds

That being said I don't reboot these systems, especially the rpi4. Which is also an answer to the stability question. I've been running a rpi4 with camillaDSP on my main system for over 2 years now. I've never experienced a glitch and I never restart other than when needed for software upgrades. It has run for several months on end without issue. Prior to this I used miniDSP systems (miniSHARC based) and would occasionally need to power cycle after switching between configurations.

The biggest issue with CamillaDSP when using an optical input will be sample rate handling. The macs are potentially an interesting option as core audio seems to recognize sample rate changes over optical, however you will still need some way to restart CamillaDSP with the new sample rate. camilladsp-set rate only works with ALSA and the USB gadget, so won't be a turnkey solution.

I played around with a TOSLINK I/O configuration on the mac mini 2012 and I think a solution could be developed pretty easily. CamillaDSP will crash if the input sample rate is changed as core audio changes the sample rate to match the new input. However, the listdevices script (https://github.com/HEnquist/cpal-listdevices) is able to correctly identify the sample rate change. If you could run the listdevices script (or something similar) every time prior to a CamillaDSP restart and then have another script change the CamillaDSP configuration file to match the currently detected input sample rate I think that would do it.

Personally, I find it easiest to deal with sample rate changes by either restricting the sample rate at the source or using an ASRC.

Michael

Thank you for this. I really appreciate it!

I now realize that I had wrongly assumed you were running Linux on your Mac Minis and doing something along these lines on the input side. (I found out about this after asking you, by the way.)

Thanks for pointing out the USB gadget aspect of camilladsp-setrate and sharing an alternative approach. I'll admit it's still a bit abstract, but it's great to have something to refer back to.

It's all still a bit tantalizing for me, undoubtedly due to specific requirements on my end.

Back to the drawing board!

 

[melomane13]

​

Thank you for this. I really appreciate it!

I now realize that I had wrongly assumed you were running Linux on your Mac Minis and doing something along these lines on the input side. (I found out about this after asking you, by the way.)

Thanks for pointing out the USB gadget aspect of camilladsp-setrate and sharing an alternative approach. I'll admit it's still a bit abstract, but it's great to have something to refer back to.

It's all still a bit tantalizing for me, undoubtedly due to specific requirements on my end.

Back to the drawing board!

@Rednaxela look at hifiberry Dac + dsp. it has input output toslink , asrc , 4 channels output, boot on seconds when used alone ( without raspberry pi) . with sigmaDsp it is "easy" to write specific program, if the standard isn't enough.​

 

[Rednaxela]

Thank you @melomane13.

Maybe better for me to take that route indeed. I’ve come across it multiple times but will research it some more. May open a separate thread for followup questions not to pollute this one too much.

 

[melomane13]

Boot time is seconds, but probably more like 45 seconds than 5 seconds. Just tried a few reboots:

mac mini 2012 (catalina 10.15.7): 38 seconds
mac mini 2014 (monterey 12.7.2): 43 seconds
rpi4 (ubuntu server 22.04): 43 seconds
HP t630 (ubuntu server 22.04): 48 seconds


Michael

Rpi ZERO 2 w , raspberryos lite:
Startup finished in 4.002s (kernel) + 19.862s (userspace) = 23.684s

disabling somes services (wifi, bluetooth, network), i get 12 sec.
of course, we cannot get access to camillagui, but camilladsp is running. ok for tv toslink static dsp...
P.S. in my television , image start after 11 sec...

 

[sarieri]

Rpi ZERO 2 w , raspberryos lite:
Startup finished in 4.002s (kernel) + 19.862s (userspace) = 23.684s

disabling somes services (wifi, bluetooth, network), i get 12 sec.
of course, we cannot get access to camillagui, but camilladsp is running. ok for tv toslink static dsp...
P.S. in my television , image start after 11 sec...

My experience is that Dietpi is much faster than Ubuntu server on rpi4 in terms of boot time.