RPi4 + CamillaDSP Tutorial

[ChristianN]

I have experimented a bit with several toslink sources > toslink 4x1 switch with remote control > minidsp 2x4 > raspberry pi with camilladsp and it worked pretty darn good. Besides the additional features, the fact that the minidsp takes different sample rates without complain and resamples everything before throwing it out to the pi, makes it a perfect toslink input card IMO.
I found the weak point was knowing which toslink input was active in the switch when you start the system, but as the one I was using had a led with a different color depending on the active input, it was easy to know once used to it.

Thx, sound interesting. Although it still requires a miniDSP just for swithing, and does not even use its DSP functions. In this case a miniDSP flex would serve the same purpose and the whole input stage of the okto seem superflous. but thanks for the idea, found someting similar here https://www.amazon.com/LiNKFOR-Digital-Aluminum-Switcher-Blue-Ray/dp/B07MLQ6YH4

 

[MCH]

Thx, sound interesting. Although it still requires a miniDSP just for swithing, and does not even use its DSP functions. In this case a miniDSP flex would serve the same purpose and the whole input stage of the okto seem superflous. but thanks for the idea, found someting similar here https://www.amazon.com/LiNKFOR-Digital-Aluminum-Switcher-Blue-Ray/dp/B07MLQ6YH4

Well I didn't mention it, but the purpose of the minidsp in my case is to have Dirac correction. Camilladsp does the channel routing to the DAC (motu m4) and xovers

 

[mdsimon2]

So all signal sources would need to go through the raspberry or okto first hand. my initial idea was, that all was send to the okto as: (TV or Streamer)> okto->raspberry>okto>8/4 ch speakers . the inputs may not be synced, but is that a problem as they are not both used at the same time.?

Take a read through the Okto manual. In Pure AES or USB / AES mode the Okto is clocked from inputs 1-2, if your source being fed to inputs 3-4 does not share a clock with your source for inputs 1-2 it will not work. And to be clear this is definitely a will not / loud crackling issue, not just an occasional dropped sample due to buffer under / overruns due to clock mismatch.

Otherwise it seems to be a little futile and then maybe I should setlle for unbalanced connections and get the MiniDSP flex 2x8 or Presonus 192 or similar pro sound card, both much cheaper ?

Honestly if you are switching configurations the Okto is probably not the best option. If you can live with unbalanced outputs the Flex 2x8 is a great option. If you want balanced outputs there are other great DACs available (MOTU Ultralite Mk5 comes to mind) and if you add the display described in this tutorial you can add tons of great functionality like volume indication and source / configuration indication. Heck you can even use it to display information from a cheap miniDSP (nanodigi or 2X4HD) using minidsp-rs if you go that route.

Michael

 

[phofman]

I did not follow the requirements in detail, but e.g. the legacy but quite good ESI Juli@ has an SPDIF receiver chip with 8 inputs, of which currently two are used for TOSLINK and coax. Switching is controlled from the alsa driver which could easily be extended for more inputs. Yes Juli@ is PCI, but inexpensive PCI-e - PCI adapters exist, no 12V/-12V voltages are required for the digital board of the soundcard, refurbished amd64 thin PC clients have PCI-e ports and cost less than bare RPi4 (including top-quality power adapters), etc.

 

[kepler]

Thanks for this helpful thread. I would like to use MPD as the player using CDSP to automatically adjust the bitrate to match the source file. In my /etc/asound.conf I've setup cdsp as pcm.camilladsp_cdsp {.... When I use aplay -D camilladsp_cdsp music.wav I see a camilladsp config gets generated and my usb dac seems to reflect the bitrate of the source. However, I can't seem to get this to work with MPD. MPD's mpd.conf has a audio_ouput section. Previous to cdsp I set this up with the loopback as

audio_output { type "alsa" name "loopback" device "hw:0,1" }

Camilladsp would then read from the other end of the loopback and it all worked albeit with everything resamped to a fixed rate. For CDSP my attempt looks like,

audio_output { type "alsa" name "camilla cdsp" device "camilla_cdsp" }
But when trying to playback it hangs and sometimes outputs the error to /var/log/mpd/mpd.log

exception: Failed to open "camilla cdsp" (alsa); Error opening ALSA device "camilladsp_cdsp"; snd_pcm_hw_params() failed: No such device

Does anyone have any experience with how to set MPD parameters with CDSP?

 

[mdsimon2]

CamillaDSP cannot resample to a constant sample rate with variable input sample rates. For example if you are playing a 44.1 kHz file and then switch to a 48 kHz file you will need to restart CamillaDSP with the new input sample rate.

I have not personally done it but if you want to implement sample rate switching take a look at the ALSA CDSP plugin -> https://github.com/scripple/alsa_cdsp.

Michael

 

[kepler]

Hi Michael, I'm not sure if your response was for me but I did use alsa_cdsp has mentioned in my post.

 

[MCH]

The objective is to leave the display+flirc head discretely under the tv and stuff the raspberry and the rest of boxes inside a cabinet just under. Will need at least 50cm.
I eventually found and ordered the one below that is 1m and has a 16 pin female connector in one end and loose Dupont connectors on the other. This gives the freedom to connect the pins freely to the raspberry gpio without needing to to do the connections myself (I never did and I don't know how easy/difficult it is)

My question was because I thought that if the long assembled cables are so rare... maybe it is for a reason!
I couldnt find a straight answer online besides "depends what you are connecting", what makes sense. So I will give it a try and see.

View attachment 240914

https://www.aliexpress.us/item/3256802826621405.html?spm=a2g0o.order_list.0.0.5d541802QQm2Tj&gatewayAdapt=glo2usa4itemAdapt&_randl_shipto=US

Just wanted to report back. The 1 meter ribbon cable for the display is working perfectly even though it looks incredibly flimsy.

Raspberry out of the way.
Next will be to find a longer toslink cable to relegate the minidsp to the cabinet as well

 

[Biblob]

Instead of a Motu Ultralite MK5, I have the MK4 version. Does anyone have any experience using this device? I'd like to know before starting this journey myself
I assume the USB functionality will work, but I wonder if the Toslink inputs would work too.

 

[mdsimon2]

Instead of a Motu Ultralite MK5, I have the MK4 version. Does anyone have any experience using this device? I'd like to know before starting this journey myself
I assume the USB functionality will work, but I wonder if the Toslink inputs would work too.

It should be similar to the Mk5. Of course you will need to change the playback/capture device name and maybe some of the channel counts (although at first glance they both look like 18 inputs x 22 outputs), also not sure if the inputs / outputs are in the same order. It also uses a different version of Cuemix so setting up the routing matrix will be different.

My only concern would be linux compatibility as some of the older MOTU interfaces were not great in this regard, have you used it with linux?

Michael

 

[Biblob]

It should be similar to the Mk5. Of course you will need to change the playback/capture device name and maybe some of the channel counts (although at first glance they both look like 18 inputs x 22 outputs), also not sure if the inputs / outputs are in the same order. It also uses a different version of Cuemix so setting up the routing matrix will be different.

My only concern would be linux compatibility as some of the older MOTU interfaces were not great in this regard, have you used it with linux?

Michael

I have no experience using it with Linux yet... Only with Windows. I do have a Linux Virtualbox at hand, would that be useful to test it with?

 

[MCH]

Hey guys,
Do you think it would be possible to skip the flirc and control camilladsp directly with a Bluetooth remote? I realised that my 2 euros AliExpress remote is bluetooth capable too...

Map Bluetooth Controller using Python - Raspberry Valley

raspberry-valley.azurewebsites.net

 

[mdsimon2]

I have no experience using it with Linux yet... Only with Windows. I do have a Linux Virtualbox at hand, would that be useful to test it with?

I would try it with the actual linux hardware you want to use. You will know if there is an issue because you will get bit crushing and channel swapping. I experienced this with a MOTU Ultralite AVB but I think I remember reading that the Mk4 was fine on linux.

Worst case you can use a miniDSP MCHstreamer or USBstreamer to send CamillaDSP processed ADAT (up to 8 channels, 24 bit, 48 kHz) to the Mk4 and use the Mk4 as a "dumb" ADAT DAC.

Michael

 

[mdsimon2]

Hey guys,
Do you think it would be possible to skip the flirc and control camilladsp directly with a Bluetooth remote? I realised that my 2 euros AliExpress remote is bluetooth capable too...

Map Bluetooth Controller using Python - Raspberry Valley

raspberry-valley.azurewebsites.net

Looks very similar to the FLIRC script, should be pretty easy to modify flirc.py to use the bluetooth remote. At first glance I think all you really need to do is change your input device (flirc=evdev.InputDevice('/dev/input/by-id/usb-flirc.tv_flirc-if01-event-kbd')) and maybe the key mapping.

Michael

 

[MCH]

Looks very similar to the FLIRC script, should be pretty easy to modify flirc.py to use the bluetooth remote. At first glance I think all you really need to do is change your input device (flirc=evdev.InputDevice('/dev/input/by-id/usb-flirc.tv_flirc-if01-event-kbd')) and maybe the key mapping.

Michael

Thanks Micheal. Will give it a try and report back. If it works I think it could have some advantages over ir (not to have to aim at the flirc anymore...). Let's see how it works

 

[mdsimon2]

Updated the tutorial to reflect updated oled.py and flirc.py scripts. Changes are mostly around configuration changes at the request of @jdubs (also thanks to @MarcosCh for trying the new routines out).

You can now specify a list of configurations to switch between in flirc.py as shown below.

In oled.py you specify the same list but can also add what you would like the first line of the display to show for each configuration in a separate list.

Previously when switching configurations or sample rates from longer to shorter text (say "CamillaDSP" to "SPDIF" or "192000 Hz" to "48000 Hz") remnants of the longer text would appear after the shorter text until the display was cleared and re-populated. I made some improvements to oled.py so that if text does not fill up the entire line it will write blank pixels until it reaches the end of the line which eliminates this issue.

Michael

 

[somebodyelse]

I have no experience using it with Linux yet... Only with Windows. I do have a Linux Virtualbox at hand, would that be useful to test it with?

It would probably work - I've done it the other way round with Windows in the virtualbox and linux as the main OS, with USB passthrough of a Focusrite Forte to the Windows VM.

 

[alto]

Has anyone set this up with Rocky Linux instead of Ubuntu Server?
I'm not against Ubuntu Server, but I do have a bunch of other devices running Rocky already in a cluster setup which allow me to install security patches centrally on all of them since they all have the same package manager. I was wondering if there is any specific functionality bundled in Ubuntu Server that is crucial for getting CamillaDSP and the audio configuration running?

 

[mdsimon2]

Has anyone set this up with Rocky Linux instead of Ubuntu Server?
I'm not against Ubuntu Server, but I do have a bunch of other devices running Rocky already in a cluster setup which allow me to install security patches centrally on all of them since they all have the same package manager. I was wondering if there is any specific functionality bundled in Ubuntu Server that is crucial for getting CamillaDSP and the audio configuration running?

I am not familiar with Rocky but if you can install all the required packages there should not be an issue.

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.

Michael

 

[alto]

I am not familiar with Rocky but if you can install all the required packages there should not be an issue.

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.

Michael

I will give it a go then and see how it goes. Rocky Linux is the successor of CentOS which in turn is a community version of Red Hat Enterprise Linux (RHEL).
How is the resource consumption on the RPi when running CamillaDSP and actively EQ'ing audio? Is there a lot of margin left for running any other processes on the side?