CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.

There was a bug in 0.6.2 that makes for very slow starts when using an Alsa Plug device. Version 0.6.2 added better debug output for Alsa. As part of that it checks each number of channels up to the max reported by the device, to see which numbers are really supported. This causes trouble with a plug device, which reports that it supports 10000 channels. Checking from 1 to 10000 takes a quite long time! Version 0.6.3 limits the check to 32.


Get version 0.6.3 here: Release v0.6.3 * HEnquist/camilladsp * GitHub
 
I am trying to accomplish a mission, but am way out of my element. What is the best way to run 4 analog's out of the RPI4, using Camilla as the DSP to setup the 2 crossover points for each channel? Preferably looking for a higher quality solution, with nice relocker and dual AKM chips (but really anything that measures well, could work). Thanks in advance!

P.S. I feel like this has been answered in here, but have searched and read through the last 25 pages and not had any luck.
 
I am trying to accomplish a mission, but am way out of my element. What is the best way to run 4 analog's out of the RPI4, using Camilla as the DSP to setup the 2 crossover points for each channel? Preferably looking for a higher quality solution, with nice relocker and dual AKM chips (but really anything that measures well, could work). Thanks in advance!

P.S. I feel like this has been answered in here, but have searched and read through the last 25 pages and not had any luck.

The Motu M4 has 1 USB C input and 4 balanced TRS outputs or 4 single ended RCA outputs (as well as 2 balanced TRS line inputs). Downside is that the front volume control only controls channels 1 and 2, so you'll need to use a software volume control. Good measurements from ASR.
 
The Motu M4 has 1 USB C input and 4 balanced TRS outputs or 4 single ended RCA outputs (as well as 2 balanced TRS line inputs). Downside is that the front volume control only controls channels 1 and 2, so you'll need to use a software volume control. Good measurements from ASR.
Thanks so much for your response and suggestion. I looked at this, and I don’t understand how exactly this will run off RPI in my scenario. What I mean is that it looks like it is powered off USB, and the RPi will not have enough voltage to power this and the WiFi/Bluetooth/chrome dongle. So, I am going to have to power it off it’s own voltage regulator off the battery pack. So, then how do I setup the RPI board to send 4 separate, already EQ’ed signals to the Motu?

The volume is going to be an issue as well, because this is all being built into a portable speaker, but that is a question for another day.

This question probably shows my ignorance, but I don’t know how else to remedy it, lol.
 
So, I am going to have to power it off it’s own voltage regulator off the battery pack. So, then how do I setup the RPI board to send 4 separate, already EQ’ed signals to the Motu?
The audio is assigned to the output channels the soundcard exposes to the operating system and is transferred by USB just as it would with any external USB soundcard. Most of the pro interface options need mains power some of the mobile ones could be bus powered but you would have to check to make sure.

An alternative is the Allo Piano 2.1 hat which has 4 outputs, the DAC's are not as good as can be made but they are not terrible either, for a portable bluetooth speaker, reclocking and sinad chasing seems a little incongruous.

The volume is going to be an issue as well, because this is all being built into a portable speaker, but that is a question for another day.
You probably should have led with the use case as it changes the options that best fit :)
 
The audio is assigned to the output channels the soundcard exposes to the operating system and is transferred by USB just as it would with any external USB soundcard.
An alternative is the Allo Piano 2.1 hat which has 4 outputs, the DAC's are not as good as can be made but they are not terrible either, for a portable bluetooth speaker, reclocking and sinad chasing seems a little incongruous.

You probably should have led with the use case as it changes the options that best fit :)

Thanks for the explanation, but I’m don’t totally understand how if the power needs to come through USB and so does the signal, yet the Pi powering the device isn’t strong enough to power the Motu via USB works. Is there some sort of power injector that I would run the Pi through to go to the Motu? Or, have I just totally missed the boat?

Also, I have become hesitant to say what the project is, on my posts, because where I lead with that- no one responds. Also, everyone seems to think building a reference level portable speaker is stupid and/or that 35 lbs and 30”x11”x12” long isn’t portable. This tends to make me want to do it more, along with the fact that no one I have seen has ever tried anything close to what I am doing. We do vacations to VRBO type houses, with other families and there are never any good tunes. I am building 2 portable speakers for this- one battery and one A/C powered. Plus I have several friends wanting me to build whatever I come up with, so I feel like pressure is on. Trying to stay around $500 for the smaller battery one, and around $1,000-$1,200 for the a/c one.

Anyways, I am over my head on the computer side, and am grateful to anyone who takes time and pity on a RPI noob, like me.
 
An alternative is the Allo Piano 2.1 hat which has 4 outputs, the DAC's are not as good as can be made but they are not terrible either

I actually contacted Allo and asked if they could do a 2.1 on the Boss2, or upgrade the Piano’s DAC, and they said no. I may end up stuck with this option but I don’t think it is that great of a product, but it is a good value. It just seems like it would be better to throw a couple Topping E30’s in, but I hate how wasteful it is. I am just surprised no one makes a good 4 or 6 out DAC board with 2-3 AK4499’s or ESS9038pros.

I guy a mentor has a programming buddy who is working on a RPI Bluetooth to WiFi ‘handshake’, where connecting to Bluetooth on the phone triggers the pi to connect to the phones hotspot. So you can then stream over the WiFi. There are some complicated issues, that are above my pay grade, but just trying to stream full quality from my phone to the speaker without any other network involvement. I fell like if that can be made to happen, a worthy DAC setup should be involved.
 
Thanks for the explanation, but I’m don’t totally understand how if the power needs to come through USB and so does the signal, yet the Pi powering the device isn’t strong enough to power the Motu via USB works. Is there some sort of power injector that I would run the Pi through to go to the Motu? Or, have I just totally missed the boat?

Also, I have become hesitant to say what the project is, on my posts, because where I lead with that- no one responds. Also, everyone seems to think building a reference level portable speaker is stupid and/or that 35 lbs and 30”x11”x12” long isn’t portable.
Devices can be bus powered where they receive 5V via the USB bus the amount of current would depend the both devices. It's possible to hack the power lines so they are provided from a source with more current or with a better power supply.

The M4 is USB-C bus powered and USB-C can provide much more power over the bus assuming the power supply and Rpi can supply it.

It just seems like it would be better to throw a couple Topping E30’s in, but I hate how wasteful it is. I am just surprised no one makes a good 4 or 6 out DAC board with 2-3 AK4499’s or ESS9038pros.
DiyinHK has a new 8 channel ES9038 board which works with their 8 channel USB board. That also has an OLED and can do volume control via the operating system. It will need power supplies and is nowhere near as compact as a HAT. I have the ES9016 version and I find it near impossible to tell the difference between it and a much fancier ES9018 stereo DAC I built. They are data sheet designs with simple I/V so they won't best Okto or Topping at who's got the biggest Sinad but they sound good enough to not worry.

8 Channels 384kHz 32bit ES9038PRO PCM DXD DSD Audio DAC - DIYINHK

Maybe start your own thread if you want to dig into that more.
 
I actually contacted Allo and asked if they could do a 2.1 on the Boss2, or upgrade the Piano’s DAC, and they said no. I may end up stuck with this option but I don’t think it is that great of a product, but it is a good value. It just seems like it would be better to throw a couple Topping E30’s in, but I hate how wasteful it is. I am just surprised no one makes a good 4 or 6 out DAC board with 2-3 AK4499’s or ESS9038pros.
The Piano uses an unusual dac chip with an embedded DSP, they can't just swap for another one.
Using two stereo dacs isn't a good way forward. It's technically possible with an Alsa multi device, but since that can't synchronize the independent clocks of the two dacs it will never work well.

You should use a single USB device with at least 4 channels. HDMI could also work. But not I2S as the Pi only supports stereo.


But I have to agree with fluid, I don't see how a portable speaker (meaning for exampel that the drivers for both channels will be mounted close together in the same unit) would be limited by the Piano dacs.
 
That is measurements of the ES9016 version and at post#10 you will see pictures of my build. My power supply setup is quite large, there are images of a more compact version using a silent switcher and some regulator boards.

Apart from buying pro interfaces the options for multichannel DAC's are still quite limited.
 
The new CoreAudio backend is getting ready. Someone wants to try?
If yes, then download and compile the "coreaudio" branch: GitHub - HEnquist/camilladsp at coreaudio

This uses CoreAudio directly, without going via CPAL. This allows things like stopping on capture rate change, and proper handling of device disconnects.
It always uses FLOAT32LE when communicating with CoreAudio, so the "format" setting in the config is gone.

The CoreAudio support is provided by my fork of the coreaudio-rs library (GitHub - HEnquist/coreaudio-rs: A friendly rust interface to Apple's Core Audio API.). I have sent a PR to get my changes included in upstream, hopefully that will get accepted.

Note that the removed "format" config parameter means this version doesn't work with the pyCamillaDSP-plot library and the GUI (yet).
 
Banned Sock Puppet
Joined 2020
IHopefully 5.15 kernel will have all patches required.

You can power your Pi through the GPIO and use the USB-C to connect to the USB host, works OK. I do not have any problem with the power line of the USB cable, supplied by the USB host. The fact is when the main PSU is disconnected, the Pi keeps running on the trickle from the USB-C connector.

Mine..
Machine model: Raspberry Pi Compute Module 4 Rev 1.0 NO WIFI.

I don't think anyone else is using this,- allows 5-30v supply.
Much better!

Lots of advantages with it and no SD card stuff + Pci-e and no onboard hdmi audio - headphone system.
Onboard memory is a quantum leap faster than normal RPi.

OS
Linux version 5.10.60-v8+ (dom@buildbot) (aarch64-linux-gnu-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1449 SMP PREEMPT

Plan is obviously to use PCi-e for multi channel audio (anything up to 64 ch over Dante) gives amazing low latency too.
It gives I/O also.
Hope to have some news over next weeks.
 
Last edited:

TNT

Member
Joined 2003
Paid Member
Fantastic news for Mac owners. I will surely test this but my circumstances right now don't allow for any trials I'm afraid. Cant you hardwire to FLOAT32LE to keep compatibility? Could be good if it shows up also even if not changeable...?

Have you endless energy Henrik? :D

//




The new CoreAudio backend is getting ready. Someone wants to try?
If yes, then download and compile the "coreaudio" branch: GitHub - HEnquist/camilladsp at coreaudio

This uses CoreAudio directly, without going via CPAL. This allows things like stopping on capture rate change, and proper handling of device disconnects.
It always uses FLOAT32LE when communicating with CoreAudio, so the "format" setting in the config is gone.

The CoreAudio support is provided by my fork of the coreaudio-rs library (GitHub - HEnquist/coreaudio-rs: A friendly rust interface to Apple's Core Audio API.). I have sent a PR to get my changes included in upstream, hopefully that will get accepted.

Note that the removed "format" config parameter means this version doesn't work with the pyCamillaDSP-plot library and the GUI (yet).
 
;)
Thanks so much for your response and suggestion. I looked at this, and I don’t understand how exactly this will run off RPI in my scenario. What I mean is that it looks like it is powered off USB, and the RPi will not have enough voltage to power this and the WiFi/Bluetooth/chrome dongle.

Just a note on RPI, USB C and power:
Infineon has made a 40 W poweramp/shield to be run from USB C 5V and RPI zero:
KIT_40W_AMP_HAT_ZW - Infineon Technologies
Also includes nice guide how to intall linux and linux audio on an RPI
Note also that the shield can run from 5V powerbank. Just saying

More literature here for arduino version:
KIT_ARDMKR_AMP_40W - Infineon Technologies