RPi4 + CamillaDSP Tutorial

[hugo1805]

Hi.
Many thanks to @HenrikEnquist and @mdsimon2 for your work!

I'm trying to run CamillaDSP in Ubuntu 23.04 with RME AES32 sound card. I get 'snd_pcm_hw_params_set_access' error:

Spoiler: log

$ /usr/local/bin/camilladsp/camilladsp -p 1234 /home/sss/camilladsp/configs/rme-aes.yml -v 2023-07-26 05:26:23.803235 INFO [src/bin.rs:711] CamillaDSP version 1.0.3 2023-07-26 05:26:23.803272 INFO [src/bin.rs:712] Running on linux, x86_64 2023-07-26 05:26:23.804704 DEBUG [src/bin.rs:754] Read config file Some("/home/serg/camilladsp/configs/rme-aes.yml") 2023-07-26 05:26:23.810825 DEBUG [src/bin.rs:773] Config is valid 2023-07-26 05:26:23.810857 DEBUG [src/socketserver.rs:260] Start websocket server on 127.0.0.1:1234 2023-07-26 05:26:23.810927 DEBUG [src/bin.rs:857] Wait for config 2023-07-26 05:26:23.810958 DEBUG [src/bin.rs:890] Config ready 2023-07-26 05:26:23.811220 DEBUG [src/filters.rs:450] Build new pipeline 2023-07-26 05:26:23.811283 DEBUG [src/processing.rs:19] build filters, waiting to start processing loop 2023-07-26 05:26:23.811609 DEBUG [src/bin.rs:213] Using channels [true, true] 2023-07-26 05:26:23.811656 DEBUG [src/alsadevice.rs:917] Buffer frames 4096 2023-07-26 05:26:23.812623 DEBUG [src/alsadevice.rs:413] Playback: supported channels, min: 16, max: 16, list: [16] 2023-07-26 05:26:23.812669 DEBUG [src/alsadevice.rs:414] Playback: setting channels to 16 2023-07-26 05:26:23.812713 DEBUG [src/alsadevice.rs:418] Playback: supported samplerates: Discrete([32000, 44100, 48000, 64000, 88200, 96000, 176400, 192000]) 2023-07-26 05:26:23.812739 DEBUG [src/alsadevice.rs:419] Playback: setting rate to 44100 2023-07-26 05:26:23.812761 DEBUG [src/alsadevice.rs:423] Playback: supported sample formats: [S32LE] 2023-07-26 05:26:23.812779 DEBUG [src/alsadevice.rs:424] Playback: setting format to S32LE 2023-07-26 05:26:23.812946 ERROR [src/bin.rs:344] Playback error: ALSA function 'snd_pcm_hw_params_set_access' failed with error 'EINVAL: Invalid argument' 2023-07-26 05:26:23.812983 DEBUG [src/bin.rs:349] Error while starting, release barrier 2023-07-26 05:26:23.813111 DEBUG [src/alsadevice.rs:413] Capture: supported channels, min: 1, max: 32, list: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32] 2023-07-26 05:26:23.813134 DEBUG [src/alsadevice.rs:414] Capture: setting channels to 2 2023-07-26 05:26:23.813159 DEBUG [src/alsadevice.rs:418] Capture: supported samplerates: Range(8000, 192000) 2023-07-26 05:26:23.813178 DEBUG [src/alsadevice.rs:419] Capture: setting rate to 44100 2023-07-26 05:26:23.813201 DEBUG [src/alsadevice.rs:423] Capture: supported sample formats: [S16LE, S24LE, S24LE3, S32LE, FLOAT32LE] 2023-07-26 05:26:23.813222 DEBUG [src/alsadevice.rs:424] Capture: setting format to S32LE 2023-07-26 05:26:23.813311 DEBUG [src/alsadevice.rs:455] Opening audio device "hw:Loopback,0" with parameters: HwParams { channels: Ok(2), rate: "Ok(44100) Hz", format: Ok(S32LE), access: Ok(RWInterleaved), period_size: "Ok(1024) frames", buffer_size: "Ok(8192) frames" }, SwParams(avail_min: Ok(2048) frames, start_threshold: Ok(0) frames, stop_threshold: Ok(8192) frames) 2023-07-26 05:26:23.813338 DEBUG [src/alsadevice.rs:460] Audio device "hw:Loopback,0" successfully opened 2023-07-26 05:26:23.813371 DEBUG [src/alsadevice.rs:958] Starting captureloop 2023-07-26 05:26:23.813421 DEBUG [src/processing.rs:21] Processing loop starts now! 2023-07-26 05:26:23.813457 DEBUG [src/bin.rs:352] Wait for capture thread to exit.. 2023-07-26 05:26:23.813535 INFO [src/alsadevice.rs:592] Capture device supports rate adjust 2023-07-26 05:26:23.813568 DEBUG [src/alsadevice.rs:627] Exit message received, sending EndOfStream 2023-07-26 05:26:23.813637 INFO [src/processing.rs:37] Playback thread has already stopped. 2023-07-26 05:26:23.813792 DEBUG [src/bin.rs:915] Restarting with new config 2023-07-26 05:26:23.813823 DEBUG [src/bin.rs:857] Wait for config 2023-07-26 05:26:23.813843 DEBUG [src/bin.rs:860] No config and not in wait mode, exiting!

Could you help me with this issue?
My config is:

Spoiler: config

devices: samplerate: 44100 chunksize: 2048 capture: type: Alsa channels: 2 device: "hw:Loopback,0" format: S32LE playback: type: Alsa channels: 16 device: "hw:HDSPMx000000" format: S32LE rate_measure_interval: 1 mixers: 2x16: channels: in: 2 out: 16 mapping: - dest: 0 mute: false sources: - channel: 0 gain: -1 inverted: false mute: false - dest: 1 mute: false sources: - channel: 1 gain: -1 inverted: false mute: false - dest: 2 mute: false sources: - channel: 0 gain: -1 inverted: false mute: false - dest: 3 mute: false sources: - channel: 1 gain: -1 inverted: false mute: false - dest: 4 mute: false sources: - channel: 0 gain: -1 inverted: false mute: false - dest: 5 mute: false sources: - channel: 1 gain: -1 inverted: false mute: false - dest: 6 mute: false sources: - channel: 0 gain: -1 inverted: false mute: false - dest: 7 mute: false sources: - channel: 1 gain: -1 inverted: false mute: false - dest: 8 mute: false sources: - channel: 0 gain: -1 inverted: false mute: false - dest: 9 mute: false sources: - channel: 1 gain: -1 inverted: false mute: false - dest: 10 mute: false sources: - channel: 0 gain: -1 inverted: false mute: false - dest: 11 mute: false sources: - channel: 1 gain: -1 inverted: false mute: false - dest: 12 mute: false sources: - channel: 0 gain: -1 inverted: false mute: false - dest: 13 mute: false sources: - channel: 1 gain: -1 inverted: false mute: false - dest: 14 mute: false sources: - channel: 0 gain: -1 inverted: false mute: false - dest: 15 mute: false sources: - channel: 1 gain: -1 inverted: false mute: false pipeline: - name: 2x16 type: Mixer

(I don't need all 16 channels, it's made for testing.)

My sound card parameters is:

Spoiler: params

$ aplay -v -D hw:HDSPMx000000 /dev/zero --dump-hw-params Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono HW Params of device "hw:HDSPMx000000": -------------------- ACCESS: MMAP_NONINTERLEAVED RW_NONINTERLEAVED FORMAT: S32_LE SUBFORMAT: STD SAMPLE_BITS: 32 FRAME_BITS: 512 CHANNELS: 16 RATE: [32000 192000] PERIOD_TIME: (333 256000] PERIOD_SIZE: [64 8192] PERIOD_BYTES: [4096 524288] PERIODS: 2 BUFFER_TIME: (666 512000] BUFFER_SIZE: [128 16384] BUFFER_BYTES: [8192 1048576] TICK_TIME: ALL -------------------- aplay: set_params:1347: Access type not available

I've made changes to the config but to no avail. I would be grateful for advice.

 

[HenrikEnquist]

It looks like that card doesn't support interleaved access, which is the mode camilladsp uses. Try adding a plug to convert. It should be ok to just change "hw" to "plughw", like this:
device: "plughw:HDSPMx000000"

 

[sebackman]

Must confess I have not read all the pages in this long thread but I have a question.

In digital audio circuits the sound quality should be reasonable the same if well implemented but in DSP solutions they are not. I have tried many out board DSP's and they do not sound the same with identical settings. It may be HW but most likely the algorithms, or a combination of both.

How good is the Camilla DSP SW compared to DEQX, DBX, Lake, BSS or other professional DSP's?

 

[tinnitus]

The CDSP is as good as the filters you use
I use 65k FIR Filter from acourate and it works very well (with latency).

 

[mdsimon2]

Must confess I have not read all the pages in this long thread but I have a question.

In digital audio circuits the sound quality should be reasonable the same if well implemented but in DSP solutions they are not. I have tried many out board DSP's and they do not sound the same with identical settings. It may be HW but most likely the algorithms, or a combination of both.

How good is the Camilla DSP SW compared to DEQX, DBX, Lake, BSS or other professional DSP's?

It is difficult to say what you are hearing (or think you are hearing) without more information. Factors that make DSPs potentially sound different:

1) Different Q definition, this is very common and will result in measurable frequency response differences -> https://www.andyc.diy-audio-engineering.org/parametric-eq-parameters/index.html. I can't say I've compared all filter types in CamillaDSP but they appear to use the same proportional Q (RBJ) definition that miniDSP uses. I've replicated the LXmini and LX521.4 DSP in CamillaDSP based on miniDSP filter definition and the frequency response is identical.

2) High frequency warping when using IIR filters at low sample rates -> https://www.audiosciencereview.com/forum/index.php?threads/minidsp-flex.28660/page-14#post-1037905. Again, this results in measurable frequency response differences although they will be less audible. Only way around this is to use higher sample rates or FIR.

3) Implementing FIR filters without enough taps to properly implement them. Again, this will result in measurable frequency response differences. CamillaDSP doesn't have this problem as you can pretty much do whatever you want in terms of tap count but some pro audio processors with limited tap counts may have some compromises here.

4) Rising noise floor when filters are implemented -> https://www.audiosciencereview.com/...sp-measurements-and-rising-noise-floor.42383/. This is probably the least audible issue of everything discussed so far but CamillaDSP does not exhibit this behavior.

Given the frequency response differences if you are trying to replicate settings from another device you owe it to yourself to have the ability to measure frequency response to verify that you are getting what you think you are getting.

Michael

 

[sebackman]

Thank you for the answers. I moved from passive to active XO/DSP back in 2003 and have been trying to catch up since .

I do have a measuring rig (HW/SW) and reasonable monitors to compare/listen. Many DSP's have passed the work shop since 2003 and it is excellent that SW & HW finally gives us the opportunity to build high quality audio with a tools like CDSP, Pi4 and cheap high quality DAC's. All at very reasonable costs.

However, from my experience when comparing different DSP units with very similar output curves (adjusted), they often do sound different. Even if the measured FR and phase is more or less the same.

You are of course right in that the filters may not be implemented the same which alters the sound. The HW DSP we use runs symmetrical constant Q filters as opposed to proportional Q in CDSP and miniDSP.

Such measurements are of course limited by measuring equipment but with calibrated gear and a short time window (acoustic measurement) the impact should be within acceptable boundaries. Yet, they do not sound the same.

I hate to say that as I'm typically on the side that everything should be measurable to carry any weight. Traditional FR, pulse and phase measurements may not capture all that can be heard.

(Disclaimer: please don't interpret the above as advocating for "the golden ear approach", I'm all for science and any short fall in explanations of perceived differences is just saying that we are looking in the wrong place or using the wrong binoculars)

Warping is normally not a problem for us as we use the DSP to correct speakers and when we measure them any potential warping would be compensated while adjusting the FR on the speaker. The chosen DSP and the speaker them becomes a "system" and if changing to a different DSP settings would probably have to be adjusted.

Rising audible noise due to added DSP objects or corrections has been a limited problem from my experience. Excellent that CDSP does not exhibit any of that.

For those using a separate DSP and feeding analogue signal into the DSP, too low levels may create audible problems for the ADC (which is not what we are talking about here).

When we feed the DSP digitally (USB, SPDIF or AES) and use digital output from the DSP to feed a high quality DAC (Okto or similar) noise is normally quite acceptable. I also find that high gain power amps often can be the source for audible noise.

I have toyed around with FIR a few years but often found that well implemented IRR gets the job done. The phase correction in the FIR filter is superior but with a good IRR filter we can shift the phase to be matching at XO and that typically works fine form an audible standpoint.

I'm in the midst of building a new set of speakers and there I will start with IRR but also ask a friend to help getting a FIR table to make them FR and phase linear (if I got enough taps). I hope they will be the end-game-speakers for me. Maybe I will base them on CDSP .

I will just have to give it a go. After tweaking the output curves of the CDSP to be the same as the separate DSP and make an A/B test to see if I can spot any difference. Probably not. At least not in my age

The challenge with A/B test is often make certain that the pre/post chain is similar in both cases to able to compare only what you want to compare and not pre and/or post equipment. I think I can do that in this case. This will be exciting.

Thank you
//Rob

 

[mdsimon2]

Such measurements are of course limited by measuring equipment but with calibrated gear and a short time window (acoustic measurement) the impact should be within acceptable boundaries. Yet, they do not sound the same.

To clarify, when I mentioned measurement capability I meant electrical measurement capability, not acoustic. Far too many variables in acoustic measurements to say you are truly listening to the same DSP response.

Warping is normally not a problem for us as we use the DSP to correct speakers and when we measure them any potential warping would be compensated while adjusting the FR on the speaker. The chosen DSP and the speaker them becomes a "system" and if changing to a different DSP settings would probably have to be adjusted.

Again, if you aren't matching the electrical response via electrical measurement and are relying on acoustic measurements when switching DSP systems I doubt you are actually listening to the same DSP response.

Michael

 

[sebackman]

Hi Michael,

Thank you for clarifying. We can of course do both with reasonable accuracy. The only way to align the DSP curves, as you are stating, would be on the electrical output side from the DSP. -Or after the power amp.

The system is full dual channel where we can have the electrical output from one DSP on the first channel, the second DSP on the other channel and overlay/delta.

Same goes for acoustic measurement.

Or mix them as we do when measuring speakers, we have the DSP out (pre or post settings) on one channel, the mic input on the other and show the difference.

Kind regards
//Rob

 

[walter-]

I want to do DRC - probably with CamillaDSP - on a RasPi. Additional requirements for the RasPi are streaming via Tidal Connect (16bit, 44.1kHz) and UPnP/DLNA. I'd like to have the DAC on the RasPi.
Then the signal goes to active monitors (TRS or XLR).

Since the RasPi, DRC and other audio issues are relatively new to me I want to ask if you recommend such a setup with a RasPi. Especially the DRC in combination with Tidal Connect and DAC (performance, audio quality, ...).
Which RasPi model would be reasonable for this setup?
Which HAT DAC (I saw the HifiBerry DAC2 Pro) do you recommend? An external DAC is a possibility if it has real advantages.

A further system extension could be 1 or 2 sub(s). What is needed to integrate them?
(Sorry if some of my questions are too off topic. If so, I could create a new thread.)

 

[somebodyelse]

If you want Tidal Connect then I think paid Volumio is the only option. I don't know whether CamillaDSP is now built in, or still a plugin. Check Volumio for hardware support, but I think it supports most hats. For subs you either need subs with built in processing like most semi-pro models, or a USB DAC with 4 channels - or 6 if you want to EQ headphones separately. I don't know whether the Volumio CamillaDSP interface can do crossovers directly, or whether you need to brew a 'special' config manually.

 

[walter-]

Before I buy a RasPi + DAC I want to make sure that the hardware fulfills my requirements.
Mainly if the DRC processing, Tidal streaming and DAC work together in a performant way. In the best case someone here at ASR uses a RasPi for these purposes.

For Tidal, additional to Volumio, I found these options:
PiCorePlayer OS: https://forums.raspberrypi.com/viewtopic.php?t=345047
Plex: https://support.tidal.com/hc/en-us/articles/360002069037-Plex
HiTide: https://github.com/shawaj/HiTide
Tidal Connect Docker image for HifiBerry (and RaspbianOS): https://github.com/TonyTromp/tidal-connect-docker

@somebodyelse, thanks for your explanations. How can I recognize a sub with built in processing?
For the other option, a 4 channel DAC for 2 loudspeakers + 2 subs (headphones not needed), would the Topping E50 work since it has TRS out and RCA out?

 

[changer]

I use pCP on a Raspberry Pi 4 2GB and it works. I listen via Deezer though.

 

[walter-]

I use pCP on a Raspberry Pi 4 2GB and it works. I listen via Deezer though.

Do you use CDSP? Which DAC do you use?

 

[changer]

not yet.

I bought all required hardware for a zigbee knob controller and eventually got some time to try install the 'superplayer', which is a pCP + CamillaDSP package. -> https://www.audiosciencereview.com/...pi-help-needed-with-python.40320/post-1524374
I have no doubts the raspberry has got enough power to handle this.

the DAC I use is part of my hypex FA123 plate amp, it is the ADAU1450. RP4 -> S/PDIF -> FA123 (ADAU1450) ..

 

[somebodyelse]

piCorePlayer uses the Logitech Media Server (LMS) which can run on the Pi or on a separate machine. You only need one instance of LMS on your network. The Tidal plugin for LMS works via mysqueezebox.com and the old Tidal interface, not Tidal Connect. Using CamillaDSP is possible via a couple of routes, but last I looked they took a reasonable amount of command line work to install. Superplayer has already been mentioned, which puts CamillaDSP between the squeezelite endpoint and the audio output. There is also a plugin for LMS in development that puts CamillaDSP in the LMS end, applying the DSP before streaming to the endpoint. If you're running both LMS and squeezelite on the same device it makes little difference which you try. I do use piCorePlayer and LMS. I haven't tried either plugin and I haven't tried the Tidal support. You could also look at daphile which runs on PC hardware like cheap thin clients (fanless, silent), and has BruteFIR integrated for DSP. The GUI only supports the convolution method, and doesn't include crossover for subs though.

Plex may be a viable option. Didn't know about the Tidal support.

HiTide hasn't been updated in 3 years, uses bad practice to install dependencies (creates a frankendebian) and uses a Tidal binary extracted from a proprietary firmware image. If you're ok with software from dubious sources and you understand what you're letting yourself in for in maintenance that's your choice. The Docker image appears to be a better packaged use of the same proprietary binary. Last time I looked at the HifiBerryOS you needed one of their DSP boards to do room correction, but that may have changed.

https://www.scan.co.uk/shop/music-and-pro-audio/speakers/subwoofers for examples of subs with onboard processing. They will have line level inputs (from the DAC or preamp) and line level outputs intended for use with active monitors, but they could be used with a power amp as well. Most have a switch to enable or disable the high pass filter for the outputs, and some have a sub defeat switch that turns off both the sub and the high pass filter. The high pass for the outputs matches the low pass for the sub, forming the crossover and meaning you don't need to do it separately in DSP upstream. You do need to be able to control the volume before the input to the sub though.

 

[changer]

There is also a plugin for LMS in development that puts CamillaDSP in the LMS end, applying the DSP before streaming to the endpoint.

Can you share more information and a link maybe?

 

[mdsimon2]

For the other option, a 4 channel DAC for 2 loudspeakers + 2 subs (headphones not needed), would the Topping E50 work since it has TRS out and RCA out?

No, the Topping E50 will not work. For a 2.2 CamillaDSP system you need a DAC that presents 4 channels to your computer, the Topping E50 is only 2 channel (TRS and RCA outputs are identical).

This tutorial has several 4+ channel DACs that work well with a RPi4 + CamillaDSP (MOTU M4, MOTU Ultralite Mk5, Okto dac8 pro), I'd also consider the Topping DM7 or running two stereo DACs with a miniDSP UDIO-8. One issue to watch out for is the Okto dac8 pro and Topping DM7 are only designed to work with devices that have balanced inputs.

Michael

 

[somebodyelse]

Can you share more information and a link maybe?

https://forums.slimdevices.com/foru...ements-for-new-dsp-plugin-please-be-realistic - I haven't been keeping up with the thread and had to find it again.

 

[sarieri]

Does anyone know whether power/data splitter wil work if I want to plug the flirc plug into the type c port?
I put type c port into host mode as instructed but the flirc plug won’t show up in the lsusb list. Everything is fine if I plug it in the back USB 2.0 ports of raspi. I tested the typec to a converter and it’s working on my PC.

 

[mdsimon2]

Does anyone know whether power/data splitter wil work if I want to plug the flirc plug into the type c port?
I put type c port into host mode as instructed but the flirc plug won’t show up in the lsusb list. Everything is fine if I plug it in the back USB 2.0 ports of raspi. I tested the typec to a converter and it’s working on my PC.

Can you confirm that the FLIRC works when plugged in to the USB C port without the power/data splitter? If it works without the splitter then it seems clear that splitter is at fault.

Michael