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

FIXED - Finally found it

Have you checked alsa-lib versions? Probably lots of changes in alsa-lib between debian 10 and 11.

Thanks for the SoX lessons. I have see I have a lot to learn.

JRMC28 is now working with Alsa_cdsp on Debian 11.

I tried running other audio players until I found one that threw the following error,
which might be what JRMC28 is encountering and aplay is not.

Code:
play 01_Rosa_Lee.wav
ALSA lib dlmisc.c:337:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_cdsp.so 
(/libx-gnu/alsa-lib/libasound_module_pcm_cdsp.so: undefined symbol: snd_lib_error)

I searched the web and found this:

ToolChain/DSOLinking - Debian Wiki
Code:
...
For the --as-needed default change, a workaround/fix would be to link with "-Wl,--no-as-needed -lfoo -Wl,--as-needed". 

Note that the --as-needed and --no-as-needed are positional parameters and the default behaviour should be restored after using this workaround. 
...

I rebuilt the alsa_cdsp driver with the suggested "-Wl,--no-as-needed -lasound -Wl,--as-needed"
linker options and JRMC28 is now able to open and write to the driver.

This must be something new between Debian 10 and 11 because the driver's Makefiles are the same.
 
IMO JRMC28 is compiled against older alsa-lib and it has problems with the new alsa-lib in Debian 11. While alsa team tries hard to keep the ABI backwards compatible, it may not work at 100% with a third party alsa plugin. IMO it would be good to consult this on the alsa-devel mailing list, at least to learn the exact reason. Maybe the discussion would result in some bugfix in alsa-lib.
 
Debian 10, grepping the strings in the 2 resulting .so yields the same results of [snd_lib_error@@ALSA_0.9 vs snd_lib_error@@ALSA_0.9].

Debian 11, grepping the strings in the 2 resulting .so yields a delta of [snd_lib_error vs snd_lib_err@ALSA_0.9], with the latter one addressing the missing symbol.

So far it works on both Debian 11's 5.10 default and 5.14 (improved USB music driver) backports kernels. Hope it doesn't mean it is regressing to an earlier version of ALSA.

Debian 10 alsa-utils is on 1.1.8-2
Debian 11 alsa-utils is on 1.2.4-1
Debian 12 alsa-utils is currently on 1.2.5.1-1

Debian 10
Code:
strings libasound_module_pcm_cdsp.so | grep snd_lib_error
snd_lib_error
snd_lib_error@@ALSA_0.9

Debian 11 - stock build
Code:
gcc -Wall -fPIC -DPIC  -O3 -march=native -mtune=native -Wall -shared -lasound -o libasound_module_pcm_cdsp.so libasound_module_pcm_cdsp.c

strings libasound_module_pcm_cdsp.so | grep snd_lib_error
snd_lib_error
snd_lib_error

Debian 11 - patched build
Code:
gcc -Wall -fPIC -DPIC  -O3 -march=native -mtune=native -Wall -shared -Wl,--no-as-needed -lasound -Wl,--as-needed -o libasound_module_pcm_cdsp.so libasound_module_pcm_cdsp.c

strings libasound_module_pcm_cdsp.so | grep snd_lib_error
snd_lib_error
snd_lib_error@ALSA_0.9
 
Last edited:
I've been happily streaming through CamillaDSP to a Moto M4 for a couple weeks now.
Could someone point me in the right direction for routing the analog line-level inputs of the Motu through CamillaDSP?

I'm using Ubuntu 21.04 (GNU/Linux 5.11.0-1012-raspi aarch64) on a Pi 4.

It's quite easy as long as you are ok with reloading the config when switching between analog in and streaming.
Use "arecord -l" to find the device name. Also try recording something with it to check that you get something. Then put the device name in your camilladsp config. You can disable rate adjust and resampling, none of that is needed.

Henrik,
Is this as simple as getting the usb card's name (in my case it's "AudioSUB" aka card 1, device 0) and entering it in the gui field "Capture device" section under "device" as AudioSUB?

I would have thought the loopback would have worked to accept multiple capture devices and send them to camilla.

Matt
 
Henrik,
Is this as simple as getting the usb card's name (in my case it's "AudioSUB" aka card 1, device 0) and entering it in the gui field "Capture device" section under "device" as AudioSUB?
Yes exactly!

I would have thought the loopback would have worked to accept multiple capture devices and send them to camilla.

Matt
Think of the loopback as simply a normal soundcard, where you have put a cable directly from line out to line in. One app can play sound to the playback side of it, and another app can record the same sound from the capture side of it. That's all.
 
Hidden Kernel 5.14 Goodies for Focusrite Scarlett Users

FYI, Kernel 5.14 has a new alsamixer that supports Gen 2 and 3 Focusrite Scarlett devices for Linux users. The feature is disabled by default, but can be easily enabled.

I have tested it with a 3rd Gen Scarlett 8i6 and it works. There is a new configuration/mixer GUI in the works as well, but hasn't been released yet.

Releases * geoffreybennett/scarlett-gen2 * GitHub

Hope this helps.
 
y8s: Typically USB audio dongles run at USB fullspeed (12Mbps). Maybe the 4th dongle, if connected to the same bus, exceeded the available fullspeed bandwidth which results in data being dropped. See https://www.microchip.com/forums/download.axd?file=0;321236&filename=FS_iso_endpoint.JPG

You data payload (packet size) is listed in /proc/asound/CARDX/stream0 when playback is active.

Here's what 1 of the 3 working dongles looks like. Not sure how to interpret it. Mostly posting for my curiosity.

Code:
$ cat AudioHIGH/stream0 
TTGK Realtek USB2.0 Audio at usb-3f980000.usb-1.1.2, high speed : USB Audio

Playback:
  Status: Running
    Interface = 1
    Altset = 3
    Packet Size = 72
    Momentary freq = 44100 Hz (0x5.8333)
  Interface 1
    Altset 1
    Format: S16_LE
    Channels: 2
    Endpoint: 7 OUT (ADAPTIVE)
    Rates: 44100, 48000, 96000, 192000, 384000
    Data packet interval: 125 us
    Bits: 16
    Channel map: FL FR
  Interface 1
    Altset 2
    Format: S24_3LE
    Channels: 2
    Endpoint: 7 OUT (ADAPTIVE)
    Rates: 44100, 48000, 96000, 192000, 384000
    Data packet interval: 125 us
    Bits: 24
    Channel map: FL FR
  Interface 1
    Altset 3
    Format: S32_LE
    Channels: 2
    Endpoint: 7 OUT (ADAPTIVE)
    Rates: 44100, 48000, 96000, 192000, 384000
    Data packet interval: 125 us
    Bits: 32
    Channel map: FL FR
 

TNT

Member
Joined 2003
Paid Member
I have come to a situation where the filter section don't allow me to add yet an other filter i.e. the 26th. I know - I should redo the whole bunch but I cant detect any SQ penalty so why not just go on :) It seem to accept the + button but no new empty filter is presented.

I'll try a request again: please import the filters from REV... once you made an house curve auto fitting you end up with quite a lot of filters and typing :-/

//
 
I have come to a situation where the filter section don't allow me to add yet an other filter i.e. the 26th. I know - I should redo the whole bunch but I cant detect any SQ penalty so why not just go on :) It seem to accept the + button but no new empty filter is presented.
Odd, there shouldn't be any limit on the number of filters. I'll take a look when I update the gui for v1.0.0.

I'll try a request again: please import the filters from REV... once you made an house curve auto fitting you end up with quite a lot of filters and typing :-/

//
Can you try this script? It translates the REW filters to the CamillaDSP format so you can paste into a config file.
camilladsp/translate_rew_xml.py at master * HEnquist/camilladsp * GitHub

Not as elegant as supporting importing directly, but far less work for me :D
 
Just got this up and running as a Volumio 3 plug-in. Nice :)



Does anyone know if the Q values used in FabFilter Pro-Q are equivalent to the Q values used in CamillaDSP's parametric EQ? I would like to fine tune the parameters in Pro-Q in real time using the great UI and then plug the results into Camilla DSP.
 
Upsampling and Sample Rates

I have a question about upsampling and sample rate processing if you don't mind. It is clear from the diagram that everything is done in Float64 from the capture thread forwards until being sent to the playback device, but not so clear about sample rates.

If the source is sample rate SR_SRC, the filters are sample rate SR_FLT and the device is sample rate SR_DEV, what is the processing sample rate ?

Thanks much.


overview.png
 
I have a question about upsampling and sample rate processing if you don't mind. It is clear from the diagram that everything is done in Float64 from the capture thread forwards until being sent to the playback device, but not so clear about sample rates.

If the source is sample rate SR_SRC, the filters are sample rate SR_FLT and the device is sample rate SR_DEV, what is the processing sample rate ?
Inside CamillaDSP the processing sample rate SR_FLT and the output device sample rate SR_DEV are always the same. Only the source sample rate SR_SRC can be different.

Normally the physical output device runs at the same SR_DEV rate, but there can be a few cases where it's different. For example if outputting to a "plughw:" Alsa device, when the requested sample rate isn't supported by the hardware. Then Alsa will insert a resampler to handle that.
 
Inside CamillaDSP the processing sample rate SR_FLT and the output device sample rate SR_DEV are always the same. Only the source sample rate SR_SRC can be different.

Normally the physical output device runs at the same SR_DEV rate, but there can be a few cases where it's different. For example if outputting to a "plughw:" Alsa device, when the requested sample rate isn't supported by the hardware. Then Alsa will insert a resampler to handle that.

Thank you for the clarification. It is very helpful for current configuration plans.

I saw this thread about potential future "Upsampling Filter(s)" in V2.0.

Can you elaborate on how it will be different than what is currently implemented ?

Will it upsample everything to a configured higher than SR_DEV rate SR_UPS to do the processing and then down convert to SR_DEV at the very end (or something else) ?

Support for upsample filter * Issue #137 * HEnquist/camilladsp * GitHub
 
Last edited:
I saw this thread about potential future "Upsampling Filter(s)" in V2.0.

Can you elaborate on how it will be different than what is currently implemented ?
It won't be very different from now, the resampling will still be at the same place in the capture thread. The difference will just be that there will be two new resampler presets that will work for integer resampling ratios. They will be "Expand" that inserts zeros between the samples, and "Decimate" that discards samples. These are useful to save processing power in special cases where there anyway is another suitable lowpass filter in the pipeline.
 
I thought I would try the camilladsp pipe input with shairport-sync named pipe output so that rate matching can be done by camilladsp instead of the shairport-sync synchronization feature.

For my setup I have shairport-sync set to output to a named pipe, there is no synchronization in this mode. For Camilla I run at a samplerate of 9600 to match my FIR filters. These are the settings for camilladsp:

samplerate: 9600
capture:
channels: 2
format: S16LE
filename: "/home/pi/shairport_pipe"
type: File
capture_samplerate: 44100
chunksize: 8192
enable_rate_adjust: true
enable_resampling: true

Works well. The only issue I have is that camilladsp does not register when the airplay active session is ended as it continues to shows camilladsp process as running with rms values being the last ones at the time the session was ended. If a new session is re-started then is goes back to normal. Pausing the audio in airplay works OK with camilla showing a paused processing state.

I have tried with shairport and camilla on a RPI 4b raspberry pi OS 64 bit and the current 32 bit OS with the same results. Shairport is version 3.3.8, Camilladsp is v 0.6.1, Backend V0.8.0, PyCamilladsp V 0.6.0