RPi + CamillaDSP Tutorial

[glc650]

You need to use rate adjust and asynchronous resampling if your capture device and playback device have different clocks and the capture device does not have the ability to dynamically adjust its clock.

Isn't this the case any time you have separate capture and playback devices? Like in my case the Topping DM7 only has USB input so I'm using hifime S2s as capture devices.

The only capture devices in my tutorial that have this clock adjustment capability are the ALSA Loopback and USB gadget, these still need rate adjust but do not need asynchronous resampling.

What about when the Mk5 is used for both capture and playback with SPDIF set as the clock source?

Assuming you aren’t running anything crazy and are just running a standard configuration the DSP should be quite low, 90% is way too high.

I don't think I am but I'm also not sure what's considered standard. I'm basically running your configs with CDSP configured for 2.1 with HAF filters. I suspect it is the HAF filters but I'm using filters on all 3 of my inputs so don't know why only the one S2 digi is a problem. For that one I had been using 256 for both chunksize and target level (now using 256/511). Soon as I changed to 64/127 the DSP load went nuts and CDSP eventually stopped. Even at 128/255 the DSP load is pretty high (but at least CDSP kept running).

 

[somebodyelse]

Isn't this the case any time you have separate capture and playback devices?

Usually, and if you don't know otherwise it's a safe assumption. Anyone with one of the exceptions would probably know about it, like pro audio interfaces sharing an external master clock.

 

[mdsimon2]

Thanks. All working on hardware loopback,0. My issue was the audio device wasn't assigned to the user group.
I had to do.... sudo usermod -aG audio <username>

Then the user could see the audio interface and loopback.

I installed a fresh Ubuntu LTS 24.04.... This issue wasn't present on my previous server version.

Interesting, thank you for the info.

To be honest I will probably just remove all references to Ubuntu at this point. I don’t use it my day to day setups so finding issues like this are difficult, especially when providing configuration files for devices I also don’t use regularly.

When this all started Ubuntu provided a newer kernel that was needed with the MOTU interfaces. But now regular raspberry pi OS works with everything and is faster.

Michael

 

[mdsimon2]

What about when the Mk5 is used for both capture and playback with SPDIF set as the clock source?

There is only one clock source option on the MOTU, you cannot specify a different clock for the capture and playback sides. Therefore they both use your specified clock source and rate adjust and resampling are not needed.

I don't think I am but I'm also not sure what's considered standard. I'm basically running your configs with CDSP configured for 2.1 with HAF filters. I suspect it is the HAF filters but I'm using filters on all 3 of my inputs so don't know why only the one S2 digi is a problem. For that one I had been using 256 for both chunksize and target level (now using 256/511). Soon as I changed to 64/127 the DSP load went nuts and CDSP eventually stopped. Even at 128/255 the DSP load is pretty high (but at least CDSP kept running).

What playback sample rate were you using? 64/127 is probably OK for 44/48 kHz but if running at higher rates you will need higher chunk size / buffer level.

It is certainly possible that specific device / DSP configurations require higher chunk size.

Michael

 

[glc650]

What playback sample rate were you using?

48 for both capture and playback.

64/127 is probably OK for 44/48 kHz

It wasn't but I'll just assume it is because of my HAF filters.

 

[phofman]

now using 256/511 ... changed to 64/127 ... at 128/255

In CDSP version v.2 the buffer is set to 2 chunks. That means it regularly receives a chunk from the DSP thread, and only two chunks fill the buffer completely (v3 has 4 chunks which is better).

The target level is an average buffer fill the feedback rate mechanism is trying to maintain, over longer time. Setting the target level at basically full buffer (256/511 etc.) means the target level can never be reached consistently - the buffer cannot be on average completely full, when the soundcard runs and continuously consumes samples from the buffer and the buffer cannot accept more samples in when being full.

 

[glc650]

In CDSP version v.2 the buffer is set to 2 chunks. That means it regularly receives a chunk from the DSP thread, and only two chunks fill the buffer completely (v3 has 4 chunks which is better).

The target level is an average buffer fill the feedback rate mechanism is trying to maintain, over longer time. Setting the target level at basically full buffer (256/511 etc.) means the target level can never be reached consistently - the buffer cannot be on average completely full, when the soundcard runs and continuously consumes samples from the buffer and the buffer cannot accept more samples in when being full.

So your saying I shouldn't be using 256/511 or I should be using some other target level with that chunksize?

 

[phofman]

So your saying I shouldn't be using 256/511 or I should be using some other target level with that chunksize?

@grizaudio: target_level needs to be about 150% of chunksize so that the feedback mechanism can work OK.

 

[grizaudio]

When this all started Ubuntu provided a newer kernel that was needed with the MOTU interfaces. But now regular raspberry pi OS works with everything and is faster.

Michael

I remember well.
I didn't realise Pi OS is faster... might need to give that a try.
Makes sense only to support one OS.... I'll check out Pi OS. Thanks again Michael.

 

[grizaudio]

In CDSP version v.2 the buffer is set to 2 chunks. That means it regularly receives a chunk from the DSP thread, and only two chunks fill the buffer completely (v3 has 4 chunks which is better).

The target level is an average buffer fill the feedback rate mechanism is trying to maintain, over longer time. Setting the target level at basically full buffer (256/511 etc.) means the target level can never be reached consistently - the buffer cannot be on average completely full, when the soundcard runs and continuously consumes samples from the buffer and the buffer cannot accept more samples in when being full.

One of my wishes is CamillaDSP could execute convolution across multiple CPU cores.
I have tested successfully using my pi4 2gb ram, @ 10 channels running 384k Taps at 192khz sampling [Feed by Roon].
Running htop you can see one core is maxing out, while the other three are cruising.
Effectively this means the Pi4 could likely process 3-4x the amount of DSP with multicore involvement.

 

[grizaudio]

Interesting, thank you for the info.

To be honest I will probably just remove all references to Ubuntu at this point. I don’t use it my day to day setups so finding issues like this are difficult, especially when providing configuration files for devices I also don’t use regularly.

When this all started Ubuntu provided a newer kernel that was needed with the MOTU interfaces. But now regular raspberry pi OS works with everything and is faster.

Michael

So I installed using Raspberry Pi OS. Soo much easier. No issues at all. Thanks for the heads up. The system took maybe 30minutes, from start to now.... Including installing Roon bridge via script.

 

[Wirrunna]

grizaudio, Raspberry Pi OS is definitely easier. I suggest that you investigate running it on a 10" screen with the Roon gui
https://github.com/wirrunna/CamillaDSP-an-implemantation

 

[glc650]

So I installed using Raspberry Pi OS. Soo much easier.

How is it easier?

 

[grizaudio]

How is it easier?

No custom terminal line commands are required to get things going, other than whats detailed in the GitHub instructions.
With Ubuntu LTS 24.04, I need to do some work arounds, for audio groups, etc.

 

[grizaudio]

grizaudio, Raspberry Pi OS is definitely easier. I suggest that you investigate running it on a 10" screen with the Roon gui
https://github.com/wirrunna/CamillaDSP-an-implemantation

That's cool, have you seen this? https://github.com/siraaris/roon-extension-cdsp
This extension connects to CamillaDSP via WebSocket, and enables Roon to control CamillaDSP's volume and muting in-app.

 

[stigger]

here is the problem: in about 40% of the times there is a distinct sound glitch that repeats every few seconds

It looks like I've found a "solution": usb_modeswitch -v 0x07fd -p 0x000b --reset-usb. I don't know who to blame: M4, the RPi USB controller or the USB drivers, but apparently something is not initializing correctly during boot. Power-cycling M4, re-plugging the USB cable or just doing the reset with the command above helps, haven't heard these sound artifacts for a few days now.

 

[terryforsythe]

No custom terminal line commands are required to get things going, other than whats detailed in the GitHub instructions.
With Ubuntu LTS 24.04, I need to do some work arounds, for audio groups, etc.

I ran into the same issue. I started over fresh with Raspberry Pi OS Lite. It has been working flawlessly.

 

[312elements]

Probably an edge case scenario but I’m getting ready to embark on my CDSP journey and making appropriate plans and purchases.

I noticed that WiiM has hdmi arc and a remote. My system will be pi based and I’m using Minidsp U-DIO8 for CDSP. If I use digital out on the WiiM plugged into one the digital inputs on the U-DIO8 and set that as my source can I just run all of my inputs through the WiiM and use it as a source selector and a volume control? I assume the answer to that is yes (but please correct if that’s a bad assumption) and if that is the case will using the WiiM to control volume result in negative consequences in terms of fidelity as opposed to using the flirc instructions in the guide? I assume yes, but thought I’d ask before ruling it out. Thanks in advance.

 

[mdsimon2]

Probably an edge case scenario but I’m getting ready to embark on my CDSP journey and making appropriate plans and purchases.

I noticed that WiiM has hdmi arc and a remote. My system will be pi based and I’m using Minidsp U-DIO8 for CDSP. If I use digital out on the WiiM plugged into one the digital inputs on the U-DIO8 and set that as my source can I just run all of my inputs through the WiiM and use it as a source selector and a volume control? I assume the answer to that is yes (but please correct if that’s a bad assumption) and if that is the case will using the WiiM to control volume result in negative consequences in terms of fidelity as opposed to using the flirc instructions in the guide? I assume yes, but thought I’d ask before ruling it out. Thanks in advance.

No direct experience with this setup but seems like it would work well. ASRC on the U-DIO8 should handle rate changes from the Wiim allowing you to run CamillaDSP at a constant sample rate. Attenuating upstream of the ASRC seems like a good idea as it minimizes the possibility of intersample over clipping.

Michael

 

[312elements]

No direct experience with this setup but seems like it would work well. ASRC on the U-DIO8 should handle rate changes from the Wiim allowing you to run CamillaDSP at a constant sample rate. Attenuating upstream of the ASRC seems like a good idea as it minimizes the possibility of intersample over clipping.

Michael

I’m glad I asked because that was not the answer I was expecting. Happy to try it out and report back since you think it should work.