RPi4 + CamillaDSP Tutorial

[mdsimon2]

Michael, I have just got this working (I think) by configuring Optical Out to TOS as you specified and then Source to Phones 1-2 Mix (L-R) as it did not turn off the amps when Source was set to USB Out Optical 1-2.
Is that right or have I got it wrong, again ? It appears to me that the Bobwire connected to TOS needs a signal that is there when music is playing and is mute when the music stops.

I just checked my setup and confirmed I have optical out set to USB Out to Optical 1-2 in Cuemix. As long as I am using the audio detect output port and not the input active port it works correctly. By setting USB Out to Optical 1-2 all that you are doing is giving the ability to treat the optical output channels as distinct channels in CamillaDSP. It is not clearly stated in the tutorial but you need to assign some channel routing to the digital output for the Bobwire to work. I do this in CamillaDSP on output channels 14/15 but you could also do it in Cuemix like you have done.

I thought it might be related to whether CamillaDSP was going in to paused status or not but I tried setting the silence_time out to 240 seconds and the Bobwire still cuts off the trigger after 60 seconds of silence even if the CamillaDSP status stays as running. I also tried both 48 kHz and 96 kHz configurations and both worked correctly.

Michael

 

[mdsimon2]

After testing the streaming and source switching via FLIRC and OLED, I have taken your advice and removed my NAD pre-amp from the audio chain.

For the recommended OLED I bought a 1 unit half width plastic rack case and mounted the oled and FLIRC on the flat faced back panel.

1U 9.5

1U 9.5

www.altronics.com.au

Snap-In Panel Mount Cable - USB A Extension Cable

This extension is a Snap-In panel mount, meaning you cut your hole and snap it in - No drilling/screws required! The 30cm cable allows you to attach to your device and have a working usb extension to the external, female USB-A port.

core-electronics.com.au

View attachment 283138

Here is a pic of piCore player with 7" screen sitting on the OLED display case. In piCore player I select player "CDSP-ULMK5" to control Squeezelite feeding CamillaDSP.

The rPi is not screwed down yet and the back of the case is open for ventilation.

The OLED allows 9 characters for display of the input so I used Squeezbox (a deliberate typo} as the name for the Squeezelite process running on the RPi 4 with CamillaDSP.

FLIRC.
I use an old Logitec Squeezebox Boom remote matched to the FLIRC. I made one change to Michael's keymap as I used the red Power button to toggle the Mute function.

On the living room system I have 3 inputs, "NAD Ctl" that uses analog from my NAD preamp, "Squeezbox" which uses the Squeezelite instance feeding CamillaDSP and "TV" for the TV sound through the CamillaDSP. The NAD is only there as a fallback, FM radio is streamed through the Squeezebox server and selected via the PiCore player "Favorites" menu.

Squeezelite

Having built piCore Players for years to stream from my Squeezebox server (LMS), I modified the Squeezelite initscript to include a player name and the modified SB extra args according to those recommended in Archimago's blog. I stream at 96000 with the conversion taking place in the LMS server. One less conversion.

# Defaults for squeezelite initscript
# sourced by /etc/init.d/squeezelite
# installed at /etc/default/squeezelite by the maintainer scripts

# The name for the squeezelite player (no blanks):

SL_NAME="CDSP-ULMK5"

# ALSA output device:

SL_SOUNDCARD="hw:Loopback,1"

# Squeezebox server (Logitech Media Server):
# Uncomment the next line if you want to point squeezelite at the IP address of
# your squeezebox server. This is usually unnecessary as the server is
# automatically discovered.
#SB_SERVER_IP="192.168.x.y"

# Additional options to pass to squeezelite:
# Please do not include -z to make squeezelite daemonise itself.
#SB_EXTRA_ARGS=""

SB_EXTRA_ARGS="-W -C 30 -r 96000-96000 -R v::4:28:95:105:45"

MUSINGS: More fun with digital filters! Archimago's "Goldilocks" Intermediate Phase suggestion...

A blog for audiophiles about more objective topics. Measurements of audio gear. Reasonable, realistic, no snakeoil assessment of sound, and equipment.

archimago.blogspot.com

Ubuntu Manpage: squeezelite - Lightweight headless Squeezebox emulator

manpages.ubuntu.com

View attachment 283140

The Motu Ultralite MK5 is sitting on a box that has 6 single end RCA to balanced converters that I built during early testing. The TV analog is converted to balanced using this. The amp on the bottom left is an N-Core from Audiophonics for the bass, the two amps on top are SMSL SH-9 THX headphone amps for mid and high. I made 4 pin XLR to banana plug cables for the SMSL amps.

Small cheap pre amp card/ boards , sound quality?

Has anyone tried any of these small cheap pre amp cards, with OP amp NE5532, from China? They hardly cost any money at all but are they ok? Attach some pictures of what it looks like (took some at random)...

www.audiosciencereview.com

AUDIOPHONICS MPA-S125NC RCA Power Amplifier Class D Stereo NCore NC122MP 2x125W 4 Ohm - Audiophonics

The Audiophonics PAS-125NC incorporates a Hypex Ncore NC122MP power amplifier module. This is a solid base to build a powerful stereo HiFi system, capable of delivering 2x75W under 8Ω.

www.audiophonics.fr

I converted this amp to balanced input by replacing the RCA sockets with a TRS sockets.

SMSL SH-9 THX Headphone Amplifier Review

This is a review and detailed measurements of the SMSL SH-9 THX headphone amplifier. Product was just released and will be available shortly. The sample I have was kindly sent to me by SHENZHENAUDIO and costs US $290. The market for high performance headphone amplifiers has become quite...

www.audiosciencereview.com

Looks awesome!

If you want some more room for text there are a few things that can be done. One is there is now a slightly smaller volume font designed for use with decimal point volume indication, however you could use the smaller font to only display two digit integers and have some more space. Another is I can shift the larger font over to the right just a bit and make room for "Squeezebox".

Michael

 

[Wirrunna]

I just checked my setup and confirmed I have optical out set to USB Out to Optical 1-2 in Cuemix. As long as I am using the audio detect output port and not the input active port it works correctly. By setting USB Out to Optical 1-2 all that you are doing is giving the ability to treat the optical output channels as distinct channels in CamillaDSP. It is not clearly stated in the tutorial but you need to assign some channel routing to the digital output for the Bobwire to work. I do this in CamillaDSP on output channels 14/15 but you could also do it in Cuemix like you have done.

Thank you for looking into this.

Trigger Output

It is easy to add a trigger output to the Ultralite Mk5 using a Bobwire DAT1. Simply connect the TOSLINK output of the Ultralite Mk5 to the Bobwire DAT1 and use the Audio Detect output port.

May I suggest adding "Make sure that channels 14/15 are not muted in the CamillaDSP mixer."

Apologies for not noticing the mute setting earlier. It all works now with optical out set to USB Out to Optical 1-2 in Cuemix.

As for Squeezbox, it is fine, not worth fiddling about to get an extra "e".

 

[Wirrunna]

I have a Sennheiser RS 185 low latency Digital Wireless Headphone System that will accept both digital PCM optical and analog RCA that have their own volume control.

I have tried connecting the optical cable to the Bobwire digital out but get no signal despite the red beam in the cable connector, I guess the signal is not PCM.

However, the Bobwire analog Audio works fine. I deleted the "volume" filter in both channel 14/15 to have the headphones working independently of the volume control on the CamillaDSP system so I can use the FLIRC/OLED as source selector but have the speakers down at really low volume.

 

[mdsimon2]

I have a Sennheiser RS 185 low latency Digital Wireless Headphone System that will accept both digital PCM optical and analog RCA that have their own volume control.

I have tried connecting the optical cable to the Bobwire digital out but get no signal despite the red beam in the cable connector, I guess the signal is not PCM.

However, the Bobwire analog Audio works fine. I deleted the "volume" filter in both channel 14/15 to have the headphones working independently of the volume control on the CamillaDSP system so I can use the FLIRC/OLED as source selector but have the speakers down at really low volume.

Hmm, that is odd. I am able to route the UL Mk5 TOSLINK output through the Bobwire to another TOSLINK input DAC without issue.

Michael

 

[Wirrunna]

Just downloaded the manual for the Sennheiser RS 185 and for optical digital it says "switch your audio source off before connecting the transmitter" , so I pulled the power from the Bobwire and the Sennheiser, waited 30 seconds, plugged the power back in to the Sennheiser then plugged power back into the Bobwire and now have sound.

 

[PenguinMusic]

Hi,

Posting here : maybe someone will be able to answer.

I use Camilla DSP in a dedicated OS for the Raspberry pi4 called rAudio1 (ex RuneAudio).

I can run it BUT : it ALWAYS outputs sound in 44.1khz (confirmed by DAC).

In that app there is a setting called "Capture rate". I've set that at 192khz... Rebooted but => still "Capture rate : 44.1khz".

Any idea what is going on here ?

Help would be geatlyt appreciated

 

[mdsimon2]

Hi,

Posting here : maybe someone will be able to answer.

I use Camilla DSP in a dedicated OS for the Raspberry pi4 called rAudio1 (ex RuneAudio).

I can run it BUT : it ALWAYS outputs sound in 44.1khz (confirmed by DAC).

In that app there is a setting called "Capture rate". I've set that at 192khz... Rebooted but => still "Capture rate : 44.1khz".

Any idea what is going on here ?

Help would be geatlyt appreciated

The CamillaDSP capture rate has nothing to do with what rate is used for playback. The capture rate is what is presented to your software player.

The playback rate (I think it is actually just called samplerate) is what determines the output rate.

In general these rates are fixed unless you have implemented something like the alsa cdsp plugin -> https://github.com/scripple/alsa_cdsp which restarts CamillaDSP when the sample rate changes.

That being said I know nothing about the specific OS you are using so can’t offer any more help beyond that.

Good luck.

Michael

 

[HenrikEnquist]

The CamillaDSP implementation in rAudio uses the Alsa loopback, but I don't know anything about the details. It's also using a customised version of the gui, no idea what has been changed there.
Using the loopback means that it can't switch playback or capture sample rate depending on the track being played. You have to stick to constant rates. The playback and processing rate should be called "samplerate" in the gui unless that has been modified. "capture_samplerate" is only used when resampling is enabled. All filters etc run at "samplerate". When resampling is enabled, you select the sample rate of the capture device with "capture_samplerate". The audio is then resampled to "samplerate" before any other processing happens.

 

[PenguinMusic]

Hi,

Thanks for your answers.

I think Camilla DSP in rAudio is broken anyways...
Why ?
Because if I apply filters to have something like pEQ and then apply those => no change
Because if I play with "Gain" slider => no change in volume.

Too bad.

I think the perfect Network streamer with included pEQ for a decent price is yet to be found.

Regards.

 

[sarieri]

I got the s2 digi today and it worked flawlessly. I have my computer resampling everything to 96khz but I do wonder if there is a way to have cdsp resampling everything so that my PC can output different sample rates. I tried the alsa-cdsp i/o plugin but I don’t know if it’s able to switch between configs of different capture device (trying to switch between s2 digi and alsaloopback).

 

[PenguinMusic]

The CamillaDSP implementation in rAudio uses the Alsa loopback, but I don't know anything about the details. It's also using a customised version of the gui, no idea what has been changed there.
Using the loopback means that it can't switch playback or capture sample rate depending on the track being played. You have to stick to constant rates. The playback and processing rate should be called "samplerate" in the gui unless that has been modified. "capture_samplerate" is only used when resampling is enabled. All filters etc run at "samplerate". When resampling is enabled, you select the sample rate of the capture device with "capture_samplerate". The audio is then resampled to "samplerate" before any other processing happens.

Hi Henrik,

OK, from your message and the prvious one, I was able to set the samplerate at 96khz.

Now I would have a question : each played track now has an output rate of 96khz, even if the original file only has 44.1 or 48klhz.
Is the file "resampled" or only played at a higher bitrate with no real modifications ?

In other words, is the fact that the file is played at 96khz instead of a LOWER bitrate altering or damaging the sound quality ?
If it does, it is just measurable or is it also audible ?

Thanks a lot for your answers.

Regards.

FRED

 

[HenrikEnquist]

Is the file "resampled" or only played at a higher bitrate with no real modifications ?

The only way to play a file at a higher bitrate without resampling is to play it too fast. That would be super obvious so there is definitely resampling going on here. It may be done by the player app, or by Alsa. I can't say which one it is here, it depends on how things are done in rAudio.

 

[Olombo]

Did anyone ever try out the asound_multidevice.conf for using 2 interfaces with same clock?

 

[volsch]

I‘m using 48KHz and 96kHz. Now I found, that paying with samplerate 96000 and after that changing to play 48000, cdsp is doing this without need for a new yml or restart. Are there negative side effects from this or can I be happy and see this as a feature?

 

[volsch]

Some small modification suggestions for the camilladsp.service

[Unit]
After=syslog.target network.target sound.target
Wants=syslog.target network.target sound.target

And at the end

[Install]
WantedBy=default.target

A headless system would not start with graphical.target.

 

[mdsimon2]

Some small modification suggestions for the camilladsp.service

[Unit]
After=syslog.target network.target sound.target
Wants=syslog.target network.target sound.target

And at the end

[Install]
WantedBy=default.target

A headless system would not start with graphical.target.

The service is just a copy of what @HenrikEnquist has on github -> https://github.com/HEnquist/camilladsp-config/blob/master/camilladsp.service. I run all my RPis headless without issue, have you actually experienced an issue?

I‘m using 48KHz and 96kHz. Now I found, that paying with samplerate 96000 and after that changing to play 48000, cdsp is doing this without need for a new yml or restart. Are there negative side effects from this or can I be happy and see this as a feature?

To make sure I understand correctly you are using a SPDIF input from a Hifiberry Digi+ I/O HAT, correct? Are you talking about varying the capture sample rate, playback sample rate or both?

I don't see how you can change either the capture sample rate or playback sample rate without modifying the yml and restarting. Can you post a log showing the behavior when you switch sample rates? Your configuration looks odd as you are using a 48 kHz capture rate with 96 kHz playback rate with no resampling.

I have found that with other SPDIF input devices if the capture rate is set higher than what the device is actually receiving CamillaDSP will detect the rate change correctly (as shown in the Capture samplerate field in the left hand side of the GUI) but this will not change configuration in any way.

Michael

 

[volsch]

@mdsimon2 Yes, had a problem with starting service under RaspberryPi OS Lite. So I changed these parts.
Seems it was the WantedBy.

The parts with after and wants are best practices for ALSA based services.

 

[HenrikEnquist]

My service file was made for systems running with a graphical desktop. I didn't consider headless systems etc and to be honest I didn't think too much about the setting of WantedBy, I just picked one that worked. For a system without a graphical desktop it definitely needs to change.

 

[IAtaman]

My service file was made for systems running with a graphical desktop. I didn't consider headless systems etc and to be honest I didn't think too much about the setting of WantedBy, I just picked one that worked. For a system without a graphical desktop it definitely needs to change.

I understand it does not work for RPI OS Lite, and it is not ideal in general but it works fine for headless Debian and Ubuntu.