RPi4 + CamillaDSP Tutorial

[Olombo]

Hi

new here and trying to get Cdsp to work with my MCH Streamer with 24i/o Firmware. So far I installed Cdsp and adapted the OktoDAC settings. I attached the yml and here is what I get for a frist run with it. Maybe someone still sees some errors? Or looks OK so far?

2022-12-28 07:37:27.588284 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2022-12-28 07:37:27.588524 INFO [src/bin.rs:712] Running on linux, aarch64
2022-12-28 07:37:27.588799 DEBUG [src/bin.rs:754] Read config file Some("/home/olombo/camilladsp/configs/mch_streamer.yml")
2022-12-28 07:37:27.620313 DEBUG [src/bin.rs:773] Config is valid
2022-12-28 07:37:27.620521 DEBUG [src/socketserver.rs:260] Start websocket server on 127.0.0.1:1234
2022-12-28 07:37:27.620976 DEBUG [src/bin.rs:857] Wait for config
2022-12-28 07:37:27.621215 DEBUG [src/bin.rs:890] Config ready
2022-12-28 07:37:27.622129 DEBUG [src/bin.rs:213] Using channels [true, true, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false, false]
2022-12-28 07:37:27.622443 DEBUG [src/alsadevice.rs:917] Buffer frames 2048
2022-12-28 07:37:27.623125 DEBUG [src/filters.rs:450] Build new pipeline
2022-12-28 07:37:27.623512 DEBUG [src/processing.rs:19] build filters, waiting to start processing loop
2022-12-28 07:37:27.631352 DEBUG [src/alsadevice.rs:413] Playback: supported channels, min: 24, max: 24, list: [24]
2022-12-28 07:37:27.631575 DEBUG [src/alsadevice.rs:414] Playback: setting channels to 24
2022-12-28 07:37:27.631830 DEBUG [src/alsadevice.rs:418] Playback: supported samplerates: Discrete([44100, 48000, 88200, 96000])
2022-12-28 07:37:27.631995 DEBUG [src/alsadevice.rs:419] Playback: setting rate to 48000
2022-12-28 07:37:27.632172 DEBUG [src/alsadevice.rs:423] Playback: supported sample formats: [S32LE]
2022-12-28 07:37:27.632316 DEBUG [src/alsadevice.rs:424] Playback: setting format to S32LE
2022-12-28 07:37:27.658675 DEBUG [src/alsadevice.rs:455] Opening audio device "hw:TDM24" with parameters: HwParams { channels: Ok(24), rate: "Ok(48000) Hz", format: Ok(S32LE), access: Ok(RWInterleaved), period_size: "Ok(256) frames", buffer_size: "Ok(2048) frames" }, SwParams(avail_min: Ok(1024) frames, start_threshold: Ok(768) frames, stop_threshold: Ok(2048) frames)
2022-12-28 07:37:27.659013 DEBUG [src/alsadevice.rs:460] Audio device "hw:TDM24" successfully opened
2022-12-28 07:37:27.659658 DEBUG [src/bin.rs:323] Playback thread ready to start
2022-12-28 07:37:27.660917 DEBUG [src/alsadevice.rs:413] Capture: supported channels, min: 24, max: 24, list: [24]
2022-12-28 07:37:27.661289 DEBUG [src/alsadevice.rs:414] Capture: setting channels to 24
2022-12-28 07:37:27.661563 DEBUG [src/alsadevice.rs:418] Capture: supported samplerates: Discrete([48000])
2022-12-28 07:37:27.661821 DEBUG [src/alsadevice.rs:419] Capture: setting rate to 48000
2022-12-28 07:37:27.662085 DEBUG [src/alsadevice.rs:423] Capture: supported sample formats: [S32LE]
2022-12-28 07:37:27.662320 DEBUG [src/alsadevice.rs:424] Capture: setting format to S32LE
2022-12-28 07:37:27.665546 DEBUG [src/alsadevice.rs:455] Opening audio device "hw:TDM24" with parameters: HwParams { channels: Ok(24), rate: "Ok(48000) Hz", format: Ok(S32LE), access: Ok(RWInterleaved), period_size: "Ok(512) frames", buffer_size: "Ok(4096) frames" }, SwParams(avail_min: Ok(1024) frames, start_threshold: Ok(0) frames, stop_threshold: Ok(4096) frames)
2022-12-28 07:37:27.665746 DEBUG [src/alsadevice.rs:460] Audio device "hw:TDM24" successfully opened
2022-12-28 07:37:27.665954 DEBUG [src/bin.rs:333] Capture thread ready to start
2022-12-28 07:37:27.666104 DEBUG [src/bin.rs:336] Both capture and playback ready, release barrier
2022-12-28 07:37:27.666275 DEBUG [src/bin.rs:338] Supervisor loop starts now!
2022-12-28 07:37:27.666448 DEBUG [src/alsadevice.rs:863] Starting playback loop
2022-12-28 07:37:27.666669 DEBUG [src/alsadevice.rs:958] Starting captureloop
2022-12-28 07:37:27.666801 DEBUG [src/processing.rs:21] Processing loop starts now!
2022-12-28 07:37:27.667275 DEBUG [src/alsadevice.rs:249] Starting capture from state: SND_PCM_STATE_PREPARED, Ready to start
2022-12-28 07:37:27.695815 INFO [src/alsadevice.rs:161] Starting playback from Prepared state
2022-12-28 07:37:32.683349 DEBUG [src/countertimer.rs:54] Pausing processing

 

[roderickvd]

What's the problem? I don't see any error messages.

 

[Olombo]

Hopefully no problem. Just my first steps and thought might be usefull to share the yml also for others. Also hoped that if I miss something maybe the pro guys will directly discover it. But as now everything else is also set up I am quite confident its OK so far.

 

[mdsimon2]

Log output looks fine.

Only a few things to note.

You mentioned in your PMs that you were using squeezelite, if you are use an ALSA loopback as a squeezelite output device / CamillaDSP capture device you will need to enable rate adjust to prevent buffer under / over runs.

The configuration does not have any volume control filters set so if you attempt to attenuate in the CamillaDSP GUI it will not actually do anything.

Michael

 

[Olombo]

Hi Michael,

as discussed via PM: squeezelite was mostly for trying a few things. I will use then only the MCHstreamer. Thanks for the hint with volume control I will check that

 

[jdubs]

Has anyone ever tried running room correction software while using CamillaDSP in Ubuntu? I have JBL 708i speakers that require a bunch of speaker correction eq filters + a compressor which I implement via CamillaDSP. I'd like to use software to generate a fir correction filter that works in combination with the speaker correction eq I have already setup in my CamillaDSP configs. I think maybe an alsa loopback could accomplish this.

For example, say I'm using REW as the measurement / eq-generating software. I would set REW's output as "Loopback X". That output would be the input in CamillaDSP. CamillaDSP's output would be my DAC. I have a Motu M4 + mic that would be the input for REW for the measurement taking.

Does that make sense?

-Jim

 

[roderickvd]

I think there are a couple of threads on that over at diyAudio.

 

[mdsimon2]

Has anyone ever tried running room correction software while using CamillaDSP in Ubuntu? I have JBL 708i speakers that require a bunch of speaker correction eq filters + a compressor which I implement via CamillaDSP. I'd like to use software to generate a fir correction filter that works in combination with the speaker correction eq I have already setup in my CamillaDSP configs. I think maybe an alsa loopback could accomplish this.

For example, say I'm using REW as the measurement / eq-generating software. I would set REW's output as "Loopback X". That output would be the input in CamillaDSP. CamillaDSP's output would be my DAC. I have a Motu M4 + mic that would be the input for REW for the measurement taking.

Does that make sense?

-Jim

I tried this with my Ultralite Mk5 and also my M4 but was not successful. It seems like once CamillaDSP is started it locks out the analog inputs in REW. It does work perfectly with CamillaDSP on Mac so it is an ALSA specific issue, not a CamillaDSP issue.

Here is the section of DIYaudio thread that @roderickvd mentioned where it was discussed -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7134479.

The somewhat hacky way around this is to use two interfaces. For example a M4 connected to a normal PC or Mac running REW which is used for the mic input and to send an analog signal in to a UL Mk5 connected to a RPi4 running CamillaDSP.

Michael

 

[jdubs]

I tried this with my Ultralite Mk5 and also my M4 but was not successful. It seems like once CamillaDSP is started it locks out the analog inputs in REW. It does work perfectly with CamillaDSP on Mac so it is an ALSA specific issue, not a CamillaDSP issue.

Here is the section of DIYaudio thread that @roderickvd mentioned where it was discussed -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7134479.

The somewhat hacky way around this is to use two interfaces. For example a M4 connected to a normal PC or Mac running REW which is used for the mic input and to send an analog signal in to a UL Mk5 connected to a RPi4 running CamillaDSP.

Michael

Thanks for the info, Michael!!

In my case I wouldn't be using the M4 for output, just input in REW. I have a Topping D10B that I use....so I wonder if that REW lockout only applies when the M4 is used as your output in CamillaDSP?

-Jim

 

[mdsimon2]

Thanks for the info, Michael!!

In my case I wouldn't be using the M4 for output, just input in REW. I have a Topping D10B that I use....so I wonder if that REW lockout only applies when the M4 is used as your output in CamillaDSP?

-Jim

If the M4 is not being used in CamillaDSP you should not have an issue. Running REW on a RPi4 is a bit a slow but it works. I don't install a GUI on the RPi4 but rather use SSH X forwarding from another computer.

Michael

 

[Yems]

I wonder if there's a convenient way to shutdown the Raspberry Pi after a listening session? I don't want to just pull the plug - so i always have to boot my PC only for shutting down the Raspberry Pi securely. Any suggestions?

 

[bluefuzz]

Any suggestions?

There are ways to wire a switch to the GPIO pins than can trigger a shutdown script. There are also cases that have a built in version of this. But I just leave mine on - the current draw is negligable even with current electricity prices - though admittedly it does feel a bit wrong ...

 

[Yems]

a shutdown script, that sounds good. Maybe there's a possibility without using the GPIO pins? Maybe something like: shutdown after 180 minutes or shutdown after xx minutes processor load below 5% (just examples)

 

[roderickvd]

I have thought about contributing something to CamillaDSP to trigger a start/stop or pause/play script when silence is encountered (or not). But I have been working on other things first. My use case would be to change the CPU frequency governor.

 

[bluefuzz]

Maybe there's a possibility without using the GPIO pins?

It's simple enough, I think, to automate a shutdown script but that won't actually cut the power to the device. You need a physical switch, 'power HAT' or case to do that ...

 

[MCH]

Has someone measured how much power a pi in idle (camilladsp not running) uses? Because if not relevant to switch it off could just be a way to kill the "auto running" function.
Mine powers a motu m4 so it could be interesting for me...

 

[Yems]

It's simple enough, I think, to automate a shutdown script but that won't actually cut the power to the device. You need a physical switch, 'power HAT' or case to do that ...

It would be great if someone could post an example of a shutdown script ... i am absolutely inexperienced with that. Finally pulling the plug after a regular OS shutdown would be acceptable for me.

 

[MCH]

It would be great if someone could post an example of a shutdown script ... i am absolutely inexperienced with that. Finally pulling the plug after a regular OS shutdown would be acceptable for me.

Today, by coincidence, researching for a different project, i stomped into this, that seems to be a way to shutdown a systemf system via a mqtt message. If it can be done on a pi running camilladsp, i have no idea:

systemctl-mqtt

MQTT client triggering & reporting shutdown on systemd-based systems

pypi.org

 

[simbloke]

A regular Linux distro won't need a script. Just connect a switch to a gpio pin and 0v (there are some that are opposite each other), edit the config.txt, that's it. Pressing the button generates an OS event that causes it to shut itself down, just like a regular power switch.

A bare bones distro like piCorePlayer actually does need a script but it's all installed and configured from its web UI.

 

[simbloke]

This could be handy for my NodeRed stuff

Today, by coincidence, researching for a different project, i stomped into this, that seems to be a way to shutdown a systemf system via a mqtt message. If it can be done on a pi running camilladsp, i have no idea:

systemctl-mqtt

MQTT client triggering & reporting shutdown on systemd-based systems

pypi.org