@sirfragles - that’s fantastic! I’m planning exactly the same: RPi5 plus Dac8x as 4x balanced outputs with Moode 5, but I’m struggling with the config. Would you mind sharing your configs in Moode and in the Camilla DSP pipeline editor Devices tab so that hopefully I can get this setup working too? (I have used Pi4 and Moode with a USB Dac and Camilla DSP before, so understand the basics). Thanks!
Could you provide some more details on the physical setup of the Pi 5 and HAT? One issue that has always frustrated me is that the SoC on the Pi is on the top of the board, the same side where all the HATs should go as well as any cooling solution, since that must contact the Soc and other components/chips on the board. Most HAT designers simply assume their HAT will be plugged in directly to the Pi board, and this blocks any possible cooling solution. There are probably fan based forced air cooling solutions that are slim enough that you could get away with a GPIO pin riser, but my fear is that these will make noise due to the small fans used. I would prefer a heat-wicking case or passive heatsink type solution.
I had a setup that used the Pi 4 and a stereo AMP hat from HiFiBerry but I could not also accommodate a cooling solution so it ran pretty hot.
The best physical layout I have encountered was some SBC that has the SoC on the underside, and it was sold with a large passive heat sink attached to it! But the DAC8x HAT only works on the Pi 5, so we are stuck with the problem.
Charlie,
use a header riser - https://core-electronics.com.au/2x2...hp7OqOQ_7IF0SuO2U-RJ6DYGrsahLUAsaAtpMEALw_wcB - and a couple of spacers for the other side (the white nylon uprights} https://core-electronics.com.au/10-sets-m3-20-nylon-standoffs.html -
the heatsink is sandwiched in the middle and works fine.
Last edited:
@Wirrunna Thanks for posting the pics. What fan and heatsink combo are you using and how do you feel about noise when the fan is running, etc.?
Using a Pi 5 with the DAC8x HAT seems like a great way to get 4 channels of balanced audio out of the Pi.
Did you need to install a HiFiBerry driver for the DAC8x or is it recognized by the Pi OS without doing anything? Does the HAT also work with Ubuntu on the Pi 5?
Using a Pi 5 with the DAC8x HAT seems like a great way to get 4 channels of balanced audio out of the Pi.
Did you need to install a HiFiBerry driver for the DAC8x or is it recognized by the Pi OS without doing anything? Does the HAT also work with Ubuntu on the Pi 5?
This - https://core-electronics.com.au/raspberry-pi-5-active-cooler.html , it spins up audibly during boot and then settles down and can't be heard as the Pi5 is not stressed by CamillaDSP.
I share your dislike of small fans, but i have found the "active cooler" so far is inaudible when mounted behind a touch screen.. The screen shown in the photo above is a 7" 1024x600 Elicrow, and the near vertical skeletal mounting of the RPi5 allows air circulation. I have a https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus/5784/4555_ED-Pi5Case-O.pdf on order and will try using the top heatsink as this is the only passive case I have found that has the screws on the top thus allowing the Pi5 to be mounted to the back of the screen.
I now have my daily use CamillaDSP tri-amp system for my K-Horns mounted on a https://www.amazon.com.au/Waveshare-10-1inch-Capacitive-Compatible-Raspberry/dp/B0BFQGZ2NV screen with JiveLite to control my Squeezebox (LMS) server. This uses a Motu Ultralite Mk5 USB audio interface.
I added dtoverlay=hifiberry-dac8x to config.txt as detailed in Michael's tutorial https://github.com/mdsimon2/RPi-CamillaDSP .
Thanks for all that detailed info! Looks like there may be a pair of Pi 5 + DAC8x in my future.
I will stop hijacking this thread now! 🙂
I will stop hijacking this thread now! 🙂
A quick question to CamillaDSP users. How are you running CamillaDSP (what platform, OS etc.), and for what purpose (crossover, room correction, preamp etc.)?
Why do I ask? I want to replace my ADAU1701 based DSP with CamillaDSP in my next preamp build. I am running CamillaDSP on a RPi 4 but I don’t like the boot up times using Raspberry Pi OS. Arch is a bit better but still slow to boot compared to my ADAU1701 based board. So I have played a bit with buildroot and it was quick to make a 160MB SD image with a quite functional Linux. Root file system is F2FS, kernel compression lzo, busybox with mdev for device management and syslogd logging to the kernel ring buffer instead of /var/log (use dmesg to read the log). I also included ALSA loopback, CamillaDSP, Python 3 and python modules usable with CamillaDSP. Boot time is around 3.5 sec until my HiFiBerry DAC+ ADC is available through ALSA and CamillaDSP is started.
Does anyone got anything faster? A lot more tweaking is possible but it might turn this stripped down Linux into a “one trick pony”, it is quite generic as it is right now. Is there a general interest for such a slimmed down Linux image for CamillaDSP? What would you like to see included or excluded?
Why do I ask? I want to replace my ADAU1701 based DSP with CamillaDSP in my next preamp build. I am running CamillaDSP on a RPi 4 but I don’t like the boot up times using Raspberry Pi OS. Arch is a bit better but still slow to boot compared to my ADAU1701 based board. So I have played a bit with buildroot and it was quick to make a 160MB SD image with a quite functional Linux. Root file system is F2FS, kernel compression lzo, busybox with mdev for device management and syslogd logging to the kernel ring buffer instead of /var/log (use dmesg to read the log). I also included ALSA loopback, CamillaDSP, Python 3 and python modules usable with CamillaDSP. Boot time is around 3.5 sec until my HiFiBerry DAC+ ADC is available through ALSA and CamillaDSP is started.
Does anyone got anything faster? A lot more tweaking is possible but it might turn this stripped down Linux into a “one trick pony”, it is quite generic as it is right now. Is there a general interest for such a slimmed down Linux image for CamillaDSP? What would you like to see included or excluded?
This would be neat to have on a Pi "DSP box" using USB gadget mode! So I would vote for including the USB gadget kernel modules 🙂
... why the insane hurry 🙂 ... 5 sec isn't that "enough" ?
//
//
I run CamillaDSP on a RPi 5
(https://www.audiosciencereview.com/forum/index.php?threads/rpi-camilladsp-tutorial.29656/)
attached to a 10.1" touch screen (https://github.com/wirrunna/CamillaDSP-an-implemantation)
CamillaDSP performs as a pre-amp (source selection, volume & tone ctl) crossover (3 way including time alignment, equalisation and phase correction for modified Klipschorns).
The CamillaDSP system is always on, the 3 stereo amps only switch on when playing. I run a Squeezebox (LMS) server that powers up at 6am and will close down if idle after 11pm.
All device tree overlays are included so the question is what should be preconfigured in config.txt and cmdline.txt etc.?
The most generic option is to include as little as possible and let the user add whats needed for a specific use case. Me personally won’t use network so no need for sshd and I am going to use serial pins to communicate with a micro controller. That might force me to use another UART for a serial console so I can log in. That is why I asked for use cases but I think I got the answer. As generic and bare-bone as possible and let the user do the final configuration. A getty on serial pins for login with TTL cable and dhcp on eth0 with dropbear as sshd for network logon. Both can easily be reconfigured or disabled by the user…
How about just publishing a script for building the image, with some configuration for buildroot. Anyone can add packages, can play with kernel options etc. IMO that's the DIY part, no need to give everything ready-made. Those not having a linux PC can use windows WSL2 for the build.
Wirrunna, thanks for describing your use case. Boot time is probably not critical for a system where the RPi is always on. The use case I am trying to solve is where you want to power it up and down like traditional A/V-equipment. I would also like to stay away from including other software like Squeezebox, Shairport-sync etc. to keep additional dependencies to a minimum. My image will focus on CamillaDSP, kernel modules, device tree overlays, ALSA and Python for integration.
That might be the best idea but some might be intimidated by buildroot. I can recommend Apple silicon in combination with UTM for arm tool chains. I install a “virtual” Debian arm to host the tool chain and build times are crazy fast on my Mac M1.
Well that's the DIY part, isn't it? IMO if someone wants to have a custom optimized image for an embedded device, it is expectable that it requires a bit of willingness to learn how the process actually works and actually do something to get it.
Otherwise I am afraid you will be flooded with requests for countless modifications/versions/changes which in most cases would take just a single/few lines in some script. Also in a few months new versions of the components will be available, maintaining the final image is a never-ending chore.
There are also some kernel modules needed, like "dwc2" and "g_audio". Is configfs available btw?
Do you know how easy or difficult it is to do this on an intel machine running Ubuntu? If that is doable, it would be possible to use GitHub actions to build and publish images automatically.
Henrik, you are right about the kernel modules, I will check what’s included in the kernel and whats included as modules…
Compiling on Intel and under Ubuntu should be no problem using cross-compiling. I haven’t had to myself since I run on Apple silicon. I will look into it and GitHub actions…
Compiling on Intel and under Ubuntu should be no problem using cross-compiling. I haven’t had to myself since I run on Apple silicon. I will look into it and GitHub actions…
Sorry, I'm dragging you back to tell you that I had the Pi5 with the heatsink+fan standing on my desk. After some noise at startup it would be quiet (yet still move when necessary).