CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc

[phofman]

@paalj: Please use the code formatting in the second layer of the menu, this is very hard to follow.

Try overwriting those two files. But my previous post applies.

 

[phofman]

@paalj : Our discussion has been off-topic to this thread for a while, please start a new one, preferrably with a gist of the posts relevant to the topic.

 

[paalj]

@CharlieLaub : I absolutely agree, I always prefer x86 unless Arm-only IO features are required (I2S, USB gadget, other interfaces).

The truth is making an ARM board run properly is always a major work. Done by RPi devs for RPi, other board vendor (in better cases) for a single kernel/distribution. Anything outside of that takes major effort for the user where some non-trivial linux skills are required, patching/compiling/deploying kernel, modifying device-tree, etc. etc. It's not for a user, but more like for a developer.

@paalj: Running a third-party distribution on Rock5 is not a trivial task and really does require some linux skills. I will have to go that path for my project, but am aware that it will be a fight. But there are not many other options as I need lots of CPU power with 768kHz multichannel in/out I2S + working usb gadget. RK3588 is one of very few SoCs practically available to try. What is your reason for using this still vastly unexplored path? I am afraid even if you get this kernel work and your snd-aloop module load, what next steps do you plan? Do you have the skills e.g. to make the dwc3 usb gadget or I2S output work? If not, why do you struggle with this unsupported board?

I bought the board a while ago with camilla in mind without checking much. I see now that this was not very smart. This is over my head. My plan is to use a DM7 over usb. As far as I could see, the only thing missing was the snd-aloop module. I am sorry for all posts in this thread and I will start a new.

 

[HenrikEnquist]

I just published new previews of camilladsp and the gui.
The new version should fix the slowness on Intel cpus, and the problems with dither types in the gui.
With a bit of luck this could be the last preview before the real 2.0 release 🙂

 

[spfenwick]

The new version should fix the slowness on Intel cpus

I can confirm this is working for me on all the configs I've tested with no slowdowns. Thanks for your great work 👍

 

[ChrisPatlach]

Just installed the latest alpha versions:
CAMILLADSP_VER="v2.0.0-alpha5"
PYCAMILLADSP_VER="v2.0.0-alpha2"
PYCAMILLADSPPLOT_VER="v2.0.0-alpha3"
CAMILLAGUI_VER="v2.0.0-alpha3"

Works great on my rpi 4b but there are a few things that dont look correct to me in the gui.

The gui shows CamillaDsp 2.0.0-alpha5 pyCamillaDSP 2.0.0-alpha2 Backend 2.0.0. I assume that the backend is the alpha3 version, I installed
https://github.com/HEnquist/camillagui-backend/releases/download/$CAMILLAGUI_VER/camillagui.zip.

Using the plotting function for a 22ms delay filter looks strange to me above 3k.

graphing of FIR filter in the filter tab looks good

but the same filter graphed from the pipeline tab gives a strange phase, maybe phase adjustment based on FIR peak location is not applied ?

The FIR filter is type raw float64bit.

I am also noticing that the Volume Out meters show a previous state after I use a short cut to load a config when CamillaDSP is in pause status.

 

[ChrisPatlach]

I am having problems with this config

changes to gain_vba dont seem to have any effects. I have muted ch 0to5 of vba in 8in8out and set vba_gain to -80 but still getting audio at the DAC ch 0 and 1.

I have attached the config file. Not sure how to attach yml file so used a txt extension instead.

Latest alpha versions are installed.

 

[HenrikEnquist]

Using the plotting function for a 22ms delay filter looks strange to me above 3k.

The group delay is calculated from the phase curve, and this makes trouble with large delays since then the phase wraps around very quickly at high frequencies. When it wraps around too quickly the phase unwrap algorithm starts missing some cycles. There is no perfect solution, the only thing to do is to increase the number of points used to calculate the curve. That pushes the problem to higher frequencies/larger delays. But it also makes the plotting slower.

but the same filter graphed from the pipeline tab gives a strange phase, maybe phase adjustment based on FIR peak location is not applied ?

Yes that is exactly what happens. The pipeline plot uses the "true" phase for every filter when calculating the combined result. That makes the phase and group delay curves for a pipeline step that contains a FIR filter quite useless unfortunately. The individual plot can be a bit smarter since it's only one filter type involved. I'll revisit the pipeline step plot at some point, but not sure how much better it can get (with reasonable effort).

 

[HenrikEnquist]

I am having problems with this config

That could be a problem with some mute setting not being respected. Can you try inserting gain filters on channels 0&1 in between the vba mixers? Do you still get sound on channels 0 and 1 if both the new gain filters and vba_gain are set to something very low?

 

[ChrisPatlach]

Thanks for the response on the graphs, I understand now.

Is this what what you wanted me to try ? I set the gain_new at -99 db.

I also set the inverting filter for gain of -80, still sound going to the DAC.

 

[HenrikEnquist]

Yes that was exactly what I meant. What do you see on the output level meter?

 

[ChrisPatlach]

I muted ch 2 to ch7 with the last config ( with gain_new added), with this config I get no sound to the DAC. I get sound if I then change the new_gain setting to 0dB.

 

[ChrisPatlach]

Ok ch 0 to 5 muted of vba in mixer, gain_new set to -99dB, gain_vba set to -80, invert filter with -80 dB gain, sound to DAC and ch 0,1 level meters responding

 

[ChrisPatlach]

Found the problem. User error... I was bypassing the filters in ch 6 and 7. Apologies.

 

[HenrikEnquist]

Ok! I'll look into adding some way for the pipeline overview graph to show when things are bypassed. That would likely have made this much easier to figure out.

 

[HenrikEnquist]

I made some improvements to the pipeline plot, to show when things are bypassed.
A single filter:




Mixers and filters:


And it's also showing when a channel is muted in a mixer:


This will be part of the 2.0 release. It's almost done, needs some more testing and probably a few bugfixes.

 

[TNT]

Please also the filter 1.0 -> 2.0 conversion...

//

 

[HenrikEnquist]

Please also the filter 1.0 -> 2.0 conversion...

That will be part of the config import feature that will come in a new gui version after 2.0. There is a fair bit of work left on that, I think it would delay the release too much to include it now.

 

[kerux]

I am having a problem with getting the USB Gadget working on a PI4. I tested the gadget with arecord and it appears to be working ok.
Here is the debug output. Is there something I am missing?

The PianoDac plays fine without using the usb gadget as the capture device.

Thanks

root@catpi4b:/home/dietpi# ./camilladsp -l debug cdsp_config.yml
2023-10-28 15:22:45.497286 INFO [src/bin.rs:711] CamillaDSP version 1.0.3
2023-10-28 15:22:45.497432 INFO [src/bin.rs:712] Running on linux, aarch64
2023-10-28 15:22:45.497573 DEBUG [src/bin.rs:754] Read config file Some("cdsp_config.yml")
2023-10-28 15:22:45.498210 DEBUG [src/bin.rs:773] Config is valid
2023-10-28 15:22:45.498326 DEBUG [src/bin.rs:857] Wait for config
2023-10-28 15:22:45.498416 DEBUG [src/bin.rs:890] Config ready
2023-10-28 15:22:45.498985 DEBUG [src/bin.rs:213] Using channels [true, true]
2023-10-28 15:22:45.499186 DEBUG [src/alsadevice.rs:917] Buffer frames 8192
2023-10-28 15:22:45.499439 DEBUG [src/filters.rs:450] Build new pipeline
2023-10-28 15:22:45.499761 DEBUG [src/processing.rs:19] build filters, waiting to start processing loop
2023-10-28 15:22:45.512378 DEBUG [src/alsadevice.rs:413] Playback: supported channels, min: 1, max: 10000, 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-10-28 15:22:45.512772 DEBUG [src/alsadevice.rs:414] Playback: setting channels to 2
2023-10-28 15:22:45.513693 DEBUG [src/alsadevice.rs:418] Playback: supported samplerates: Range(4000, 4294967295)
2023-10-28 15:22:45.513948 DEBUG [src/alsadevice.rs:419] Playback: setting rate to 44100
2023-10-28 15:22:45.514308 DEBUG [src/alsadevice.rs:423] Playback: supported sample formats: [S16LE, S24LE, S24LE3, S32LE, FLOAT32LE, FLOAT64LE]
2023-10-28 15:22:45.514534 DEBUG [src/alsadevice.rs:424] Playback: setting format to S16LE
2023-10-28 15:22:45.530149 DEBUG [src/alsadevice.rs:455] Opening audio device "plughw:CARD=PianoDACPlus,DEV=0" with parameters: HwParams { channels: Ok(2), rate: "Ok(44100) Hz", format: Ok(S16LE), access: Ok(RWInterleaved), period_size: "Ok(1024) frames", buffer_size: "Ok(8192) frames" }, SwParams(avail_min: Ok(4096) frames, start_threshold: Ok(3072) frames, stop_threshold: Ok(8192) frames)
2023-10-28 15:22:45.530277 DEBUG [src/alsadevice.rs:460] Audio device "plughw:CARD=PianoDACPlus,DEV=0" successfully opened
2023-10-28 15:22:45.530747 DEBUG [src/bin.rs:323] Playback thread ready to start
2023-10-28 15:22:45.537536 DEBUG [src/alsadevice.rs:413] Capture: supported channels, min: 1, max: 10000, 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-10-28 15:22:45.537638 DEBUG [src/alsadevice.rs:414] Capture: setting channels to 2
2023-10-28 15:22:45.538389 DEBUG [src/alsadevice.rs:418] Capture: supported samplerates: Range(4000, 4294967295)
2023-10-28 15:22:45.538482 DEBUG [src/alsadevice.rs:419] Capture: setting rate to 44100
2023-10-28 15:22:45.538984 DEBUG [src/alsadevice.rs:423] Capture: supported sample formats: [S16LE, S24LE, S24LE3, S32LE, FLOAT32LE, FLOAT64LE]
2023-10-28 15:22:45.539089 DEBUG [src/alsadevice.rs:424] Capture: setting format to S16LE
2023-10-28 15:22:45.539696 DEBUG [src/alsadevice.rs:455] Opening audio device "plughw:CARD=UAC2Gadget,DEV=0" with parameters: HwParams { channels: Ok(2), rate: "Ok(44100) Hz", format: Ok(S16LE), access: Ok(RWInterleaved), period_size: "Ok(1024) frames", buffer_size: "Ok(16384) frames" }, SwParams(avail_min: Ok(4096) frames, start_threshold: Ok(0) frames, stop_threshold: Ok(16384) frames)
2023-10-28 15:22:45.539821 DEBUG [src/alsadevice.rs:460] Audio device "plughw:CARD=UAC2Gadget,DEV=0" successfully opened
2023-10-28 15:22:45.539951 DEBUG [src/bin.rs:333] Capture thread ready to start
2023-10-28 15:22:45.540044 DEBUG [src/bin.rs:336] Both capture and playback ready, release barrier
2023-10-28 15:22:45.540137 DEBUG [src/bin.rs:338] Supervisor loop starts now!
2023-10-28 15:22:45.540337 DEBUG [src/processing.rs:21] Processing loop starts now!
2023-10-28 15:22:45.540668 DEBUG [src/alsadevice.rs:863] Starting playback loop
2023-10-28 15:22:45.540683 DEBUG [src/alsadevice.rs:958] Starting captureloop
2023-10-28 15:22:45.541219 INFO [src/alsadevice.rs:592] Capture device supports rate adjust
2023-10-28 15:22:45.541352 DEBUG [src/alsadevice.rs:249] Starting capture from state: SND_PCM_STATE_PREPARED, Ready to start
2023-10-28 15:22:45.910137 WARN [src/alsadevice.rs:262] Wait timed out, capture device takes too long to capture frames
2023-10-28 15:22:45.910320 DEBUG [src/alsadevice.rs:735] Capture device is inactive, processing is stalled
2023-10-28 15:22:46.280539 WARN [src/alsadevice.rs:262] Wait timed out, capture device takes too long to capture frames
2023-10-28 15:22:46.280716 DEBUG [src/alsadevice.rs:735] Capture device is inactive, processing is stalled

 

[HenrikEnquist]

The gadget is a bit quirky in that it doesn't provide any audio data if other machine isn't actively playing any sound. If you start playing something, then the capture device should exit the stall state right away.