RPi4 + CamillaDSP Tutorial

[mdsimon2]

Hello Michael, thank you very much for your support. I've just returned the MiniDSP Flex und bought a Motu M4. Now CamillaDSP works flawlessly.

How do you perform measurements with REW? Do you connect the Motu to another computer, perform the measurements on the computer, create filters and export them to CamillaDSP? Or is it necessary to perform the measurements on CamillaDSP (Pi4)?

Which mic are you using?

It is possible to run REW on a RPi4 that is also running CamillaDSP but there are some issues. In my experience running CamillaDSP on an ALSA based linux system will lock out the input channels of the interface if the same interface is being used as a CamillaDSP playback device. This is discussed in more detailed in the posts linked below.

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

Sorry, don't understand the question! Could be either of yes, no, or maybe Ha... typically me i guess... ;) Well i would like the following : squeezelite (different samplerates) ----> Cdsp (stdin) resample all to 48000 ---> Cdsp working with only 48000 fir's etc. ---> Soundcard/usbdac...

www.diyaudio.com

RPi4 + CamillaDSP Tutorial

This is great news. Could you please post your capture settings? I can't get it to work yet... Sure. I am not home but will do. But have you first connected the minidsp to a pc and selected toslink as the input? Just in case. I think otherwise the default is line in.

www.audiosciencereview.com

You can use a separate interface or mic without issue, for example a USB mic like the UMIK-1 works. The issue with this is that with a USB mic you cannot clock sync to your playback interface so you will never be able to make reliable phase measurements which are helpful for x-over design.

As a result I've found it best to use two interfaces. For example a MOTU M4 connected to a Mac running REW going in to the analog inputs of a MOTU Ultralite Mk5 which is connected to a RPi4 running CamillaDSP. This way you can use an analog mic with a physical loopback on the M4 and get good timing data. @Wirrunna has a nice detailed write-up of this approach here -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7213813.

Michael

 

[HenrikEnquist]

If we are talking about the pi (?) yes.
I don't want different streams of audio mixed together, I want one at a time. (particularly as my application is to have CLi VLC running basically headless). So basically I use Alsa to prevent other media systems from taking over or mixing with a given stream.

Alright, it's a dedicated audio playback system and you are not using it as a "normal" desktop. Then it makes sense that you do not miss (or even want) the functionality that pulse provides.

@fatoldgit how about you?

 

[Spezialtrick]

Which mic are you using?
You can use a separate interface or mic without issue, for example a USB mic like the UMIK-1 works. The issue with this is that with a USB mic you cannot clock sync to your playback interface so you will never be able to make reliable phase measurements which are helpful for x-over design.

As a result I've found it best to use two interfaces. For example a MOTU M4 connected to a Mac running REW going in to the analog inputs of a MOTU Ultralite Mk5 which is connected to a RPi4 running CamillaDSP. This way you can use an analog mic with a physical loopback on the M4 and get good timing data.

I‘m using an UMIK-1 microphone. What about using an analog input of the Motu to connect with my Laptop via trs cable for REW measurements?

Is it possible to eliminate the timing issue, if i’m using the acoustic timing reference option in the measurement window of REW?

Sorry for all my newbie questions…

 

[Daverz]

I‘m using an UMIK-1 microphone. What about using an analog input of the Motu to connect with my Laptop via trs cable for REW measurements?

Is it possible to eliminate the timing issue, if i’m using the acoustic timing reference option in the measurement window of REW?

Sorry for all my newbie questions…

Generate two 24-bit/48 kHz measurement file for left and right speakers with an acoustic timing reference (under Generator -> Sweeps -> Measurement) that you can copy to your music server for playback. Select "Save to file", and check Left only, then Right only. Put the timing reference on the left for both files so both have the same reference.

When you take a measurement, select "Use acoustic timing reference." Then click Start and start playback of measurement file from the server. REW should start recording with the first chirp, otherwise adjust your volume. REW will adjust the measurement for clock drift using the initial and final chirps.

You could plug thew computer running REW directly into the Motu, taking care with volume levels, but you still need the acoustic timing reference, and it's more convenient to play back from the music server if it's already set up that way.

 

[Wirrunna]

I‘m using an UMIK-1 microphone. What about using an analog input of the Motu to connect with my Laptop via trs cable for REW measurements?

Is it possible to eliminate the timing issue, if i’m using the acoustic timing reference option in the measurement window of REW?

Sorry for all my newbie questions…

What is your goal ?

These links should get you on the way -

Getting Started with REW - A Step-by-Step Guide

This is a rather simplified setup guide written by AustinJerry. If you need more detailed help, please start a new thread in the Official REW (Room EQ Wizard) Support Forum

www.avnirvana.com

Some guides to REW and acoustic measurement

MiniDSP UMIK-1 setup article MiniDSP loudspeaker measurement article using REW and UMIK-1 REW, UMIK-1 and HDMI on Windows AustinJerry's guide to setting up REW with USB microphones and HDMI How to set up your mac for REW Automotive Sound with miniDSP Products and REW Realtraps Room Measuring...

www.avnirvana.com

Active Bi-Amping/Tri-Amping FAQ

“What is Active Bi-Amping/Tri-Amping?” Active bi-amping uses one amplifier for low frequencies and another for mid-to-high frequencies—per audio channel. Tri-amping adds one more amplifier for a 3-way system tweeter. This is done via the use of an active crossover unit which is inserted between t...

community.klipsch.com

 

[Spezialtrick]

Generate two 24-bit/48 kHz measurement file for left and right speakers with an acoustic timing reference (under Generator -> Sweeps -> Measurement) that you can copy to your music server for playback. Select "Save to file", and check Left only, then Right only. Put the timing reference on the left for both files so both have the same reference.

When you take a measurement, select "Use acoustic timing reference." Then click Start and start playback of measurement file from the server. REW should start recording with the first chirp, otherwise adjust your volume. REW will adjust the measurement for clock drift using the initial and final chirps.

Thank you! That’s sound good. I‘ll give it a try tomorrow.

Which player are you using on shell without gui?

 

[Spezialtrick]

What is your goal ?

Actually just measuring and room correction of a 2.1 system.

 

[Daverz]

Thank you! That’s sound good. I‘ll give it a try tomorrow.

Which player are you using on shell without gui?

I suppose you could use aplay to play the wav files.

I have LMS running on a machine in another room and sqeezelite running on the RPi, which is connected to the Motu via USB.

 

[Spezialtrick]

I have LMS running on a machine in another room and sqeezelite running on the RPi, which is connected to the Motu via USB.

Ok. My setup is identical. It’s even simpler.

 

[Daverz]

Ok. My setup is identical. It’s even simpler.

I like to convert the wav files to flac and tag them appropriately, but you can always just browse folders.

 

[Wirrunna]

I suppose you could use aplay to play the wav files.

I have LMS running on a machine in another room and sqeezelite running on the RPi, which is connected to the Motu via USB.

Another LMS user here with squeezelite on a PiCorePlayer with the 7" screen that feeds a receiver that acts as a pre-amp and source selector (LMS, FM Tuner and audio out from the TV) and into a Motu Ultralight Mk 5 as analog then via USB to a RPi 4 running CamillaDSP.

Just in the final testing stage of Squeezelite running on the same RPi 4 as CamillaDSP, FM Radio is streamed and comes through LMS, volume control is handled by a FLIRC and an old Logitech remote for a Squeezebox , the TV audio will remain analog through the Motu UL5 and Michael's new Flirc script will switch CamillaDSP between a streamer config and an analog config.
The PiCorePlayer will remain but the "Choose Player" will be set so the screen controls the Squeezelie instance feeding CamillaDSP.

 

[valve_integrator]

Alright, it's a dedicated audio playback system and you are not using it as a "normal" desktop.

well yes, as we discussed many times, as an in car entertainment system the CM4 is about the only viable Linux based solution when you want to move away from smartphones and all the nonsense they bring (short battery life, poor reception, 5V USB basis, bluetooth kludging, poor DAC etc etc).

What you DON'T want in car is a desktop, you simply want the smartphone devices to control stuff such as with the excellent VLC CLi server interface. (it's an in car internet radio running at fibre optic speeds).
It becomes another IOT device.

Fact is, once you get the whole system running nicely at 12-14V, on ARM with Camilladsp it makes me wonder why it's never been done before.
It has taken the best part of 12 months to sqaush the nasty bugs, the last barrier being how to get roaming working on 4g when the other bit is running an in car wifi/4g router via a m.2 interfaced dedicated 4g card.
(wow...that was a struggle, with absolutely no help from anyone least of all the Raspi org).
It takes about 5W to make the whole thing run, inc the RF section+sim card with camilla+loop+vlc Cli as services.

"Fix it yourself", inc most of the time not bothering with the complications of REW, and performing analysis of the peaks and troughs manually.
Heck even for headphones this DSP makes an absolute transformation of any sennheiser.
Eg. using Linkwitz's measurements I even made an ancient HD414 perform like something hi end modern!

The computer housing is a tweaked special produced by our local laser printing shop, going thru several iterations to get it right, while the computer board itself for the CM4 is an IOT special produced locally in Lausanne.

IOT for camillaDSP and all the other connected services, it's got to be the way to go. (you can even talk to it via VPN if you care to go there).

 

[Spezialtrick]

Another LMS user here with squeezelite on a PiCorePlayer with the 7" screen that feeds a receiver that acts as a pre-amp and source selector (LMS, FM Tuner and audio out from the TV) and into a Motu Ultralight Mk 5 as analog then via USB to a RPi 4 running CamillaDSP.

That’s a nice setup. I assume that the Motu mk5 is feeding a poweramp? How many channels do you proceed on the mk5+CamillaDSP combo? Do you have problems with audio delay problems while watching tv?

 

[Wirrunna]

That’s a nice setup. I assume that the Motu mk5 is feeding a poweramp? How many channels do you proceed on the mk5+CamillaDSP combo? Do you have problems with audio delay problems while watching tv?

The Motu UL Mk5 feeds 3 stereo amps, all described here - https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7213813
TV Audio Delay - I have a recent Hi Sense tv and it has audio delay adjustment buried in it's setup, so I have adjusted the delay a bit, but as we sometimes watch TV using its crappy speakers so now both (the tv internal speakers and the stereo system) are out of sync, but not by much. I set the FIR filters in CamillaDSP to 4096 taps so that is not too bad.

 

[Auke te Winkel]

Starting point is a RPi4 (2 GB, 4 GB or 8 GB are all fine) running Ubuntu Server 64 bit. I prefer Ubuntu Server as it is very stable and works well with all multichannel DACs mentioned in this tutorial (and historically had a newer kernel than Raspberry Pi OS and other audio distros). We will set up CamillaDSP such that it is always running on the RPi4 as a service. A web browser based GUI is available to configure CamillaDSP after initial setup. CamillaDSP requires a capture device and playback device, the capture device is your input and playback device is your output.

There are 1GB variants of the Raspberry Pi 4 around as well. Was this option omitted intentionally or would this suffice as well? (I tried searching this thread but couldn't find an answer)

 

[valve_integrator]

There are 1GB variants of the Raspberry Pi 4 around as well. Was this option omitted intentionally or would this suffice as well? (I tried searching this thread but couldn't find an answer)

The Rpi4 with 1Gb works perfectly OK also.
I rarely see even a 3B+ hitting the memory limit unless you start opening several web pages and run HD video on a desktop.

Again I literally can't understand the fixation with Ubuntu server.
It's in any case based on DEBIAN (see what apt-get does if you don't believe it).
The main beef I have with Ubuntu, is how you can't control the processes going on in the background unless you take a lot of trouble to deinstall them or stop them working.
I found, you need the lightest possible OS to get a satisfactory experience with Linux and a light desktop.

If you want to test how light the OS is, grab the SD card out of a Rpi4, and see if it runs OK on a 3B+.
If it doesn't, then likely as anything it's too bloated.
I did most of my devs on a 3B+ and it taught a thing or 2 about what not to do.

"The Raspberry Pi 3 has 1 GB of RAM in the B and B+ models"

 

[mdsimon2]

There are 1GB variants of the Raspberry Pi 4 around as well. Was this option omitted intentionally or would this suffice as well? (I tried searching this thread but couldn't find an answer)

When I wrote the tutorial the RPi4 1 GB had been discontinued has since been re-introduced.

I've run CamillaDSP on a 1 GB CM4 module and it works fine. The only issue I ran in to is back when I was compiling CamillaDSP from source, the 1 GB module could not do it and would freeze in the middle. But starting from a pre-compiled binary as documented in this tutorial works without issue.

Again I literally can't understand the fixation with Ubuntu server.
It's in any case based on DEBIAN (see what apt-get does if you don't believe it).
The main beef I have with Ubuntu, is how you can't control the processes going on in the background unless you take a lot of trouble to deinstall them or stop them working.
I found, you need the lightest possible OS to get a satisfactory experience with Linux and a light desktop.

Fixation on Ubuntu? There is only one person in this thread that is fixated on Ubuntu and it is you. I've explained why I prefer Ubuntu throughout this thread.

I prefer Ubuntu Server as it is very stable and works well with all multichannel DACs mentioned in this tutorial (and historically had a newer kernel than Raspberry Pi OS and other audio distros).

I use Ubuntu as historically it came with a newer kernel than Raspian (Raspberry Pi OS) which was needed for some multichannel DACs. These days I could probably switch to something else but still have issues on Raspberry Pi OS with the MOTU Ultralite Mk5 (it knocks out the RPi4 wifi when connected via USB) so stick with Ubuntu.

If you want to start another thread about running CamillaDSP on a light desktop based system and find another distro works better for that application go ahead. Until then please stop polluting this thread.

Michael

 

[valve_integrator]

When I wrote the tutorial the RPi4 1 GB had been discontinued has since been re-introduced.

The only issue I ran in to is back when I was compiling CamillaDSP from source, the 1 GB module could not do it** and would freeze in the middle. But starting from a pre-compiled binary as documented in this tutorial works without issue.

Fixation on Ubuntu?

*"still have issues on Raspberry Pi OS with the MOTU Ultralite Mk5 (it knocks out the RPi4 wifi when connected via USB) so stick with Ubuntu"...

please stop polluting this thread.

Michael

**Strange you must have done something wrong!
My original camillaDSP from source was done on a RPI3+ on Buster, which cannot have more than 1Gb ram.
No problem at all to do it, so I transferred this version to all my other CM4s ever since, and it works perfect.

MOTU must the problem.
I have zero issues neither with running a m.2 LTE/4G modem (which is seen as USB device) nor with the Ian canada DAC-HAT nor with CM4 based WIFI (which is running as internet access hot spot), all simultaneously and for weeks on end.. It's not the (debian) OS then to blame.

The poster asked a straight question, I answered it, because I still use my 3B+ for all sorts of things inc desktop and watching HD video.
Keeping the Gui light means it will do it without breaking a sweat.
It was Buster had the bugs (used to crash video and stuff like Youtube regularly).
Since Bullseye it doesn't do it any more, all with just 1Gb RAM and a slower CPU.

 

[HenrikEnquist]

MOTU must the problem.

The Ultralite is a bit unusual. It presents itself as two usb devices. One audio device, and one network interface. The network interface is used for configuration by the Motu windows & macOS software (and not useful at all on Linux afaik). This new network interface likely confuses the network config on some systems. Ubuntu seems to handle this fine, while RPiOS has trouble.

 

[Spezialtrick]

Generate two 24-bit/48 kHz measurement file for left and right speakers with an acoustic timing reference (under Generator -> Sweeps -> Measurement) that you can copy to your music server for playback. Select "Save to file", and check Left only, then Right only. Put the timing reference on the left for both files so both have the same reference.

When you take a measurement, select "Use acoustic timing reference." Then click Start and start playback of measurement file from the server. REW should start recording with the first chirp, otherwise adjust your volume. REW will adjust the measurement for clock drift using the initial and final chirps.

You could plug thew computer running REW directly into the Motu, taking care with volume levels, but you still need the acoustic timing reference, and it's more convenient to play back from the music server if it's already set up that way.

Which samplerate are you using in squeezelite? 48 kHz or 44.1khz like @mdsimon2 suggested?

I've just tried to measure my 2.1 System with REW, playing the 24-bit/48khz sweeps via squeezlite and i'm getting very strange echos at the end of the sweeps, if the m4_streamer_44c_96p_10212022.yml config file from @mdsimon2 is actived. Only if i'm using the m4_streamer_44c_44p_10212022.yml config file from @mdsimon2 there are no echos in the playback.

Is it necessary to change the squeezelite config from

SL_SOUNDCARD="hw:Loopback,1"
SB_EXTRA_ARGS="-W -C 5 -r 44100-44100 -R hLE:::28"

to

SL_SOUNDCARD="hw:Loopback,1"
SB_EXTRA_ARGS="-W -C 5 -r 48000-48000 -R hLE:::28"

and create a camilladsp config which only works with 48khz samplerate to match the 24-bit/48khz REW sweeps and playback them without echos?