• 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

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'm still having an intermittent issue with CamillaDSP going off line, and needing to reboot my Pi. I'm digging through my log file to try find the cause. The other warning I had I fixed by increasing the buffer size for camilladsp-setrate.

EDIT: Digging around I noticed I forgot to set my location when I setup Raspberry Pi OS Lite. It defaulted to the UK, but I am in the US. I just changed it. I doubt that was the cause of the issue. I'll see if it happens again.

EDIT 2: I just created a script file to restart both CamillaDSP and camilladsp-setrate. I will give that a try next time it happens to see if that works to avoid having to reboot.
Another weird issue I noticed today: If I use "sudo reboot now" the WiFi does not come back up on reboot. If I use "sudo shutdown -r now" it seems to work perfectly fine.
 
Last edited:
I'm still having an intermittent issue with CamillaDSP going off line, and needing to reboot my Pi.
When this happens, is you pc still able to play something to the gadget usb device? That doesn't work in my case, pressing play in the player app just makes it hang for a while and then give some error.
 
Maybe this is a good place to ask my questions about RPI vs PC plus DAC for an active speaker. I want to go one of those ways because MiniDSP Flex is limited in FIR taps and doesn't support streaming without something else added to the mix. Ultimately, I want to stream to my active 4-way DIY speakers from my cellphone or desktop PC on my home wifi network.

When I look at Raspberry Pi, I see an incredible infrastructure of pieces but am at a loss for what to pick from among them. On top of that, it seems a fan is needed for cooling and fans are anathema to me. I see some fanless cases but don't trust what I see. I only know of one choice for an 8 ch DAC and it has single ended outputs and uncertain specs. I'm a little ham fisted with regard to software so I would not fare well trying to work through all the software issues getting my particular collection of RPI parts to run and then do what I want. If I could buy a ready to run RPI system I would be tempted to buy it.

In contrast to that, I can buy a fanless miniPC off the shelf for anywhere from $200 up and couple it with a USB DAC such as Topping E70. I've been DIYIng speakers for some time now first with miniDSP and later with JRIVER on a PC doing a mix of FIR and IIR. I can develop on my desktop the JR and the USB DAC and then port to a miniDSP running Linux and CamillaDSP to get away from constant updates and occasional crashes. Hopefully, I could make this system run headless (w/o keyboard, mouse, and monitor) only plugging them in to get back up after a crash or for an upgrade.

Is that a reasonable plan? What are the challenges I would face going to Camilla/Linux, I'm scared to ask?
 
Maybe this is a good place to ask my questions about RPI vs PC plus DAC for an active speaker. I want to go one of those ways because MiniDSP Flex is limited in FIR taps and doesn't support streaming without something else added to the mix. Ultimately, I want to stream to my active 4-way DIY speakers from my cellphone or desktop PC on my home wifi network.
It would work excellent for the purpose, regardless if you run CamillaDSP on a mini-PC or a Raspberry Pi. This thread is for Raspberry Pi though, and the guide on page 1 enables a person with zero knowledge of Linux to get it up and running (myself being an example of that). Also this thread is a wealth of knowledge and helpful people. Not sure if you will find similar resources for running it on a mini-PC.

When I look at Raspberry Pi, I see an incredible infrastructure of pieces but am at a loss for what to pick from among them. On top of that, it seems a fan is needed for cooling and fans are anathema to me. I see some fanless cases but don't trust what I see.
You don't need cooling fans for a Raspberry Pi 4, which is fully sufficient for CamillaDSP. A passive case is sufficient (I use a FLIRC case). I don't own a Pi 5, but for the low load CamillaDSP would exert on a Pi 5, passive cooling would probably suffice too. The Pi 5 only needs active cooling if you plan to put a lot of load on it, according to the internet.

I only know of one choice for an 8 ch DAC and it has single ended outputs and uncertain specs.
You don't have to use a HAT DAC with a Raspberry Pi. You can just connect a DAC via USB. For your purpose, an audio interface is probably better. E.g. a Moto M4 which is mentioned in the guide (I use a Scarlett 4i4 gen3).

I'm a little ham fisted with regard to software so I would not fare well trying to work through all the software issues getting my particular collection of RPI parts to run and then do what I want. If I could buy a ready to run RPI system I would be tempted to buy it.
With the guide on page 1 you should be able to get it up and running without knowledge of Linux. And this thread is a good place if you run into trouble. CamillaDSP has a bit of a learning curve. You will need to put some time into it.

In contrast to that, I can buy a fanless miniPC off the shelf for anywhere from $200 up and couple it with a USB DAC such as Topping E70.
The Topping E70 only has 2 outputs. You need 4. Hence why an audio interface is the answer.

Hopefully, I could make this system run headless (w/o keyboard, mouse, and monitor) only plugging them in to get back up after a crash or for an upgrade.
You can remote into the Pi from a terminal and reboot it. You never need to connect k/m or monitor, not even for the setup.


Is that a reasonable plan? What are the challenges I would face going to Camilla/Linux, I'm scared to ask?
Your main challenge will be getting the streaming part set up. There are guides for squeezebox, and airplay. You can find guides for Spotify connect on the internet too. What services do you plan using to stream to it?
 
Thanks, You've just about convinced me to try the RPI4 with a USB DAC. Confirmation that no fan is needed and the support available here is compelling.
I actually need 8 outputs and there is was a Topping that has them, perhaps I got the part number wrong. Or two 4 output DACs with a USB cable from master speaker on one side to slave speaker on the other. And I would also have an audio interface for measurement...
 
It would work excellent for the purpose, regardless if you run CamillaDSP on a mini-PC or a Raspberry Pi. This thread is for Raspberry Pi though, and the guide on page 1 enables a person with zero knowledge of Linux to get it up and running (myself being an example of that). Also this thread is a wealth of knowledge and helpful people. Not sure if you will find similar resources for running it on a mini-PC.


You don't need cooling fans for a Raspberry Pi 4, which is fully sufficient for CamillaDSP. A passive case is sufficient (I use a FLIRC case). I don't own a Pi 5, but for the low load CamillaDSP would exert on a Pi 5, passive cooling would probably suffice too. The Pi 5 only needs active cooling if you plan to put a lot of load on it, according to the internet.


You don't have to use a HAT DAC with a Raspberry Pi. You can just connect a DAC via USB. For your purpose, an audio interface is probably better. E.g. a Moto M4 which is mentioned in the guide (I use a Scarlett 4i4 gen3).


With the guide on page 1 you should be able to get it up and running without knowledge of Linux. And this thread is a good place if you run into trouble. CamillaDSP has a bit of a learning curve. You will need to put some time into it.


The Topping E70 only has 2 outputs. You need 4. Hence why an audio interface is the answer.


You can remote into the Pi from a terminal and reboot it. You never need to connect k/m or monitor, not even for the setup.



Your main challenge will be getting the streaming part set up. There are guides for squeezebox, and airplay. You can find guides for Spotify connect on the internet too. What services do you plan using to stream to it?

If I understood correctly, he needs 8 channel for his 4-way speakers and although 2x 4-channel audio interfaces could do the job, he might run into clock issues with 2 usb output.
That then leaves him with a 8ch DAC, either I2S or usb.
On the case of RPi5 (needed if going I2S), with FIR filters it will run on the hot side if not properly cooled. How strongly are you @nc535 against fans? You could build a custom case with larger fans spinning at low speed and that would be completely inaudible. As you pointed though, the only I2S 8ch available so far is not perfect.
You might be better off with a RPi4 in a well designed fanless (or not) case and a usb 8ch DAC.

In any case if you want to go with a x86 system, it is completely doable but you will not benefit from the feedback from users on this thread/forum and you will still have the same audio hardware requirements, it will cost more (to buy and to run) and take more space.

I think the first thing you need to sort out is which interface/dac you want to go with.

Edit: just read your reply @nc535, sounds like my post was not necessary :)
 
Thanks, You've just about convinced me to try the RPI4 with a USB DAC. Confirmation that no fan is needed and the support available here is compelling.
I actually need 8 outputs and there is was a Topping that has them, perhaps I got the part number wrong. Or two 4 output DACs with a USB cable from master speaker on one side to slave speaker on the other. And I would also have an audio interface for measurement...
I am not versed to diy active speakers so I do not really understand the master/slave speaker problem. That said, maybe @mdsimon2 can chime in to talk about running 2 output usb dacs, but from my recollection of his words, this is a recipe for trouble...

Edit: he is probably going to suggest an Okto dac8 :)
 
Last edited:
Thanks, You've just about convinced me to try the RPI4 with a USB DAC. Confirmation that no fan is needed and the support available here is compelling.
I actually need 8 outputs and there is was a Topping that has them, perhaps I got the part number wrong. Or two 4 output DACs with a USB cable from master speaker on one side to slave speaker on the other. And I would also have an audio interface for measurement...
I misread the 4 way speakers as 4 channels. You could use a Motu UltraLite mk5 (also part of the guide) instead then, it has 10 channels. The Topping you think of is the DM7 and it has to my knowledge been discontinued. The only place I found that still has it is Aliexpress for $1200. If I needed 8 channels, I would probably personally prefer the Motu UltraLite.
 
I was hoping for something smaller but if not and probably can't be because of panel space needed for connectors, then Ultralite it will be...
 
Thanks, You've just about convinced me to try the RPI4 with a USB DAC. Confirmation that no fan is needed and the support available here is compelling.
I actually need 8 outputs and there is was a Topping that has them, perhaps I got the part number wrong. Or two 4 output DACs with a USB cable from master speaker on one side to slave speaker on the other. And I would also have an audio interface for measurement...

The Topping DM7 is nice in that it has a display, IR volume control and a trigger out. However, I think the lack of ability to clock sync to another source is detriment when making acoustic measurements with meaningful phase information. It is also discontinued but may be available used.

I definitely would NOT recommend two four channel USB DACs as you will have clock sync issues.

I use the Okto dac8 pro and Ultralite Mk5 every day and I like them a lot. Okto is a better option for a more consumer friendly package as it has a display, IR volume control and trigger output. They have also released some interesting on board DSP functionality.

Ultralite Mk5 has a lot of good I/O, the knob on the front panel can control volume of all analog outputs which is nice if you do not need IR volume control.

To me the big advantage of the RPi is the GPIO pins which can integrate a display. This is nice if you are using the Ultralite Mk5 which doesn't have very large consumer friendly display and you want to implement an OLED display like I describe in the tutorial. If using something like the Okto there is really no difference between a PC and the RPi, although I'd probably run Linux on the PC as I like a bare bones setup and in terms of CamillaDSP setup it is much easier. I've experimented a bit with a HP T630 PC running Ubuntu and it works well with CamillaDSP, it is also completely passively cooled -> https://www.parkytowers.me.uk/thin/hp/t630/.

Michael
 
I found the thread with the DAC 8X review and it clears up my FUD about the part. I would characterize it as just good enough, compared to the Okto and Motu, which are clearly more than good enough. I will have a sensitive compression driver tweeter but the potential hiss problem is cured by preceding it with a 10W resistor/attenuator. I may need opamps between the DAC and my amps to get enough voltage and to drive long lines to the second speaker. If I find the DAC-8x lacking, I can switch to an Ultralite, which I will need anyway for measurements. But the hat-dac gives me the chance to embed the DSP system in the back panel of my active speaker, next to the plate amp. I want these speakers to reside in our living room absent the traditional rack of audio equipment and be something my technophobe wife can also turn on and enjoy.

Hifiberry's data sheet for the DAC-8x illustrates my problem with the RPI in general. It's not a real engineering data sheet, so its inherently unsatisfying to an engineer and why I was perhaps too quick to turn away from RPI. (Ironically, I got my engineering degrees from a university whose initials are RPI.) It doesn't even identify the DAC chips or the connectors used. I guess that is why we need these forums. I appreciate your willingness to share your no doubt hard won expertise. I would also gladly share mine should you ever want to DIY a PCIe or CXL switch :) or ABEC simulate a speaker concept, something I've been doing a lot of lately.

But I'm a hardware engineer and architect and I've always had an IT department and worked alongside software/firmware teams, which is why I shy away from being too hands on with software. Really far back in the day, I actually wrote a floppy disk driver for a CPM BIOS in Z80 assembler but no code since except for Verilog compiled into gates and flipflops for ASICs.

I've got some catch up reading and research to do, a lot of it in this thread, and so I'm going to do it before bothering anyone with more questions. I appreciate the help so far.

Jack
 
When this happens, is you pc still able to play something to the gadget usb device? That doesn't work in my case, pressing play in the player app just makes it hang for a while and then give some error.
No. Regardless of whether I stream from my WiiM to my Pi via USB or try to use tidal-connect running on the Pi, camillaDSP isn't receiving the stream until I reboot.
It didn't happen yesterday, but happened again today. This time restarting CamillaDSP and camilladsp-setrate got it working again.

I setup a script so that I can just type "rcam" instead of typing out "sudo systemctl restart camilladsp camilladsp-setrate" each time.
 
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
Thanks Michael!

As far as I can tell (asked ChatGPT) the Sonos Port has a fixed bitrate 44.1 kHz sample rate and 16-bit depth signal. The Automatic Optical/RCA switch looks cool and looks like just what I was initially looking for.

But it is interesting that using the 2X4HD that I already have) is an even better (and more stable) option. Sounds like a good plan to use this as a capture device and do all room corrections in the RPi/CamillaDSP instead.

I have another good DAC (SMSL SU-1), the drawback is that it is only stereo and I need a third (LFE) channel for my subwoofer. I think I can use the HAT on the RPi for the LFE. According to Geekworm, it has 112db SNR, and THD of 0.0019% (https://wiki.geekworm.com/DACPi) which should be enough for the LFE channel.

Is there any problem using two different outputs in CamillaDSP or does it support multiple soundcards (i.e.internal HAT + USB -> SMSL SU-1)?
 
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.

Thanks, this is what I thought. But when it comes to networking equipment (where I have more experience), there is always a bit of latency added when you do signal processing even with the fastest ASICs. But I guess a few milliseconds does not matter as long as it is added evenly for all channels and frequencies :)
 
Is there any problem using two different outputs in CamillaDSP or does it support multiple soundcards (i.e.internal HAT + USB -> SMSL SU-1)?
The current version of CamillaDSP only takes one output but you can merge two soundcards into one.
Have a look there:

I did this to merge two spdif outputs and it works as intended, I never tried to combine a HAT and a USB output though.
As usual, beware of clock sync issues between your two outputs. The HAT DAC need to be synced to the USB clock, if that is even possible, I do not know. Other option is to go spdif to the smsl dac.
 
As usual, beware of clock sync issues between your two outputs. The HAT DAC need to be synced to the USB clock, if that is even possible, I do not know.
If you combine outputs in pipewire instead of alsa I think it will now do ASRC to keep clocks in sync if configured correctly. I may have misinterpreted the presentation slides though.
 
Is there any problem using two different outputs in CamillaDSP or does it support multiple soundcards (i.e.internal HAT + USB -> SMSL SU-1)?

I would not do it, much better to have something that is clock sync'd, otherwise you will have variable phase issues which will mess with your crossover.

As @somebodyelse mentioned there are software ASRC solutions to this, Mac OS has had this capability for some time using an Aggregate Device. The Mac functionality seems OK for a bass crossover, but the relative delays between the two devices are not constant between machine restarts -> https://www.audiosciencereview.com/...need-ca-25-ms-delay.40051/page-2#post-1411908.

Michael
 
Michael, thank you for https://github.com/mdsimon2/RPi-CamillaDSP/blob/main/flirc_v3.py, works fine.

I've been looking for the post by @phofman about recommended chunk size and target_level for v3. Have you experimented with these in any configs?

With V3, I've been using 3x chunk size per @phofman's guidance here -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7673239. I will likely update the tutorial to use 3x but will wait for official V3 release and want to measure latency.

Michael
 
Back
Top Bottom