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

Jump to Latest
lykkedk

lykkedk

Member
Joined 2002
Sorry, don't understand the question! Could be either of yes, no, or maybe
Click to expand...
Ha... typically me i guess... ;)

Well i would like the following :

squeezelite (different samplerates) ---->
Cdsp (stdin) resample all to 48000 --->
Cdsp working with only 48000 fir's etc. --->
Soundcard/usbdac receiving 48000 only.

So i don't want samplerate switching on this configuration (only on incoming signal and done by Cdsp)

This is to avoid that squeezelite would have to convert all samplerates to 48000, as i believe that you're resampler is better.

Reason is that i would like all fir's at 48000 only duo to my umik1 mic. is native 48000

Hope it's clear now?
Maybe it's allready possible?

Jesper.
 
  • Like
Reactions: 1 user
lykkedk

lykkedk

Member
Joined 2002
Whoow ... :)

I really hope you understood my quistion?

squeezelite (different samplerates) ----> Cdsp (stdin) resample all to 48000 --->
Cdsp working with only 48000 fir's etc. ---> soundcard/usbdac receiving 48000 only.

[stdin] in my setup is the CamillaDSP Capture samplerate right ?

CaptureBOX.PNG


Samplerate (top of picture/cdsp gui) is the samplerate the capture samplerate is converted to right ?

TopGUI.PNG


And the Resampling box, is where you choose what the fixed-capture samplerate is, right ?

ResamplingBox.PNG


Well, i will try doing some experiementation tonight, but must honestly say it's hard for me to understand the explanation regarding overriding config values.

Overriding config values​


There are a few options to override values in the loaded config file. Giving these options means the provided values will be used instead of the values in any loaded configuration. To change the values, CamillaDSP has to be restarted. If the config file has resampling disabled, then overriding the samplerate will change the samplerate parameter. But if resampling is enabled, it will instead change the capture_samplerate parameter. If then enable_rate_adjust is false and capture_samplerate=samplerate, then resampling will be disabled. When overriding the samplerate, two other parameters are scaled as well. Firstly, the chunksize is multiplied or divided by integer factors to try to keep the pipeline running at a constant number of chunks per second. Secondly, the value of extra_samples is scaled to give the extra samples the same duration at the new samplerate. But if the extra_samples override is used, the given value is used without scaling it.
Click to expand...

cdsp-samplerates.PNG


Jesper.
 
HenrikEnquist

HenrikEnquist

Member
Joined 2016
@lykkedk Capture samplerate is the rate that the capture device runs at. For stdin that is the rate of the incoming data stream. The normal samplerate is the rate that the pipeline with all filters, and the playback device run at.

  • If you have a config with resampling disabled, then the two must be equal. If you override the samplerate (with the CDSP plugin for example) they will still be equal, so the override changes them both.
  • If you have a config with resampling enable, then they are allowed to be different. Overriding then only changes the capture samplerate. The filters, and the playback device stay at the samplerate from the config file.

Did this help?
 
  • Like
Reactions: 2 users
HenrikEnquist

HenrikEnquist

Member
Joined 2016
  • Like
Reactions: 6 users
ChrisMmm

ChrisMmm

Member
Joined 2005
HenrikEnquist said:
I finally finished the v1.0.0 release of the gui! There are no functional changes compared to the last rc.

The versions to use now are:
camilladsp v1.0.1: https://github.com/HEnquist/camilladsp/releases/tag/v1.0.1
pycamilladsp v1.0.0: https://github.com/HEnquist/pycamilladsp/releases/tag/v1.0.0
pycamilladsp-plot v1.0.2: https://github.com/HEnquist/pycamilladsp-plot/releases/tag/v1.0.2
camillagui-backend v1.0.0: https://github.com/HEnquist/camillagui-backend/releases/tag/v1.0.0
Click to expand...
Hi, just installed the gui (rest was up to date) just to be current. I noticed that camilladsp reports in the log and main display as 1.0.0 So reinstalled latest camillaDSP but still reporting as 1.0.0. Have I missed something?
 
M

mdsimon2

Member
Joined 2013
Neigh said:
Would anyone mind putting together a little guide / explainer around how to get everything running on macOS? I’m a little bit confused exactly what bits and pieces are required to get going.
Click to expand...

The GitHub lays it out very well but here is a condensed version of the basic steps assuming you are on an intel mac and have homebrew installed. Obviously the path where you install it will vary.

Download and unpack binary.

wget https://github.com/HEnquist/camilladsp/releases/download/v1.0.1/camilladsp-macos-amd64.tar.gz
tar -xvf camilladsp-macos-amd64.tar.gz

Install python and dependencies.

brew install python
pip3 install websocket_client aiohttp jsonschema

Install pycamilladsp and pycamilladsp-plot.

pip3 install git+https://github.com/HEnquist/pycamilladsp.git
pip3 install git+https://github.com/HEnquist/pycamilladsp-plot.git

Download and unzip GUI.

wget https://github.com/HEnquist/camillagui-backend/releases/download/v1.0.0/camillagui.zip
unzip camillagui.zip -d camillagui

Make configs and coeffs directories.

mkdir configs
mkdir coeffs

Install blackhole 2ch (or 16ch if needed).

brew install blackhole-2ch

Start camilladsp by running /path/to/binary/camilladsp /path/to/config/config.yml -p 1234

Start the GUI by running python3 /path/to/camillagui/main.py

You access the GUI by going entering http://yourhostname:5000 in a browser.

I use launchctl to start camilladsp and the GUI automatically (see attached for my com.camilladsp.plist and com.camillagui.plist). I've also attached a basic configuration that I use with a MOTU M4. I had to add a .txt on the end of these files to get them to upload so be sure to remove that.

Michael
 

Attachments

  • com.camillagui.plist.txt
    646 bytes · Views: 135
  • com.camilladsp.plist.txt
    921 bytes · Views: 123
  • m4_streamer.yml.txt
    1.4 KB · Views: 150
  • Like
Reactions: 2 users
Neigh

Neigh

Member
Joined 2022
Thank you so much for this mdsimon2. I had a go tonight and managed to get camilladsp running, with signal visible on the meters of my M4 (YAY!!) Had some trouble trying to run the GUI ERROR:asyncio:unhandled exception during asyncio.run() shutdown but I think it might be something to do with my earlier attempts to get up and running via the install script over miniconda... ill try clean things up and try again (another day though, I am too frazzled by the commandline for one day lol).
 
  • Like
Reactions: 1 user
HenrikEnquist

HenrikEnquist

Member
Joined 2016
ChrisMmm said:
Hi, just installed the gui (rest was up to date) just to be current. I noticed that camilladsp reports in the log and main display as 1.0.0 So reinstalled latest camillaDSP but still reporting as 1.0.0. Have I missed something?
Click to expand...
That seems odd. Are you shure you are really starting the new binary, or could there be an old one still lurking around?
merlin el mago said:
I'm newby, sorry if answered before: Camila DSP can support DSD files?

Now I'm using Daphile + Amanero + noDac LPF

TIA
Felipe
Click to expand...
There is no DSD support, you need to convert to PCM. DSP and DSD don't fit well together. In theory it's possible to do, but it's very inconvenient and computationally heavy.
Neigh said:
Thank you so much for this mdsimon2. I had a go tonight and managed to get camilladsp running, with signal visible on the meters of my M4 (YAY!!) Had some trouble trying to run the GUI ERROR:asyncio:unhandled exception during asyncio.run() shutdown but I think it might be something to do with my earlier attempts to get up and running via the install script over miniconda... ill try clean things up and try again (another day though, I am too frazzled by the commandline for one day lol).
Click to expand...
Please post the entire error message. There should be some clue to what is going on.
 
H

Henris

Member
Joined 2020
CamillaDSP + REW + MOTU UltraLite MK5 on Fedora 36, unable to get analog inputs working simultaneously with playback
I have a working active speaker prototyping setup using CDSP with a separate UMIK-1 USB-microphone. To get better and consistent measurement timings I planned to switch to loopback measurements using an analog microphone connected to MK5 and one of it's inputs for the reference signal. I'm currently using local sources (Spotify) for playback so I have not needed MK5's inputs before.

The problem I have encountered is that I'm unable to both record with the microphone in REW and playback through CamillaDSP at the same time. If I start CamillaDSP before REW, using microphone (eg. in REW sound meter) just fails. If I start REW and activate sound meter before CDSP, CDSP errors with device busy and also the REW sound meter fails after that. Both work nicely individually, a side issue is that the capture side on MK5 seems to be stuck at 48kHz regardless of any pipewire config.

What I have done so far:
  • In general I have followed the camilladsp-config guide for setting up Alsa loopback as the default system playback device. I had some problems trying to figure out relevant parts and how to modify the instructions to my setup but I think the barebone config is ok. It is working for playback.
  • Using pavucontrol set the MK5 in Pro Audio mode to get the individual input and output channels
  • Create a virtual source for the microphone in pipewire configuration following this example and selected it as the default input device in OS settings
  • Selected in REW the "default (default)" as the output and input devices. The device lists do not contain neither the Alsa loopback nor the virtual source.
  • Monitored the nodes and links using pw-top, pw-mon, Helvum with no apparent reason for not working to together.
  • Countless hours of reading alsa, pipewire, wireplumber and fedora related docs and forum posts to no avail

I can definitely provide heaps of additional info (configs, error messages, screenshots on Helvum etc,) but I thought to first ask if there is larger known issue with this kind of setup.

Any help is well appreciated.
 
  • Like
Reactions: 1 user
C

CharlieLaub

Member
Joined 2007
audio.claub.net
Paid Member
Henris said:
CamillaDSP + REW + MOTU UltraLite MK5 on Fedora 36, unable to get analog inputs working simultaneously with playback
I have a working active speaker prototyping setup using CDSP with a separate UMIK-1 USB-microphone. To get better and consistent measurement timings I planned to switch to loopback measurements using an analog microphone connected to MK5 and one of it's inputs for the reference signal. I'm currently using local sources (Spotify) for playback so I have not needed MK5's inputs before.

The problem I have encountered is that I'm unable to both record with the microphone in REW and playback through CamillaDSP at the same time. If I start CamillaDSP before REW, using microphone (eg. in REW sound meter) just fails. If I start REW and activate sound meter before CDSP, CDSP errors with device busy and also the REW sound meter fails after that. Both work nicely individually, a side issue is that the capture side on MK5 seems to be stuck at 48kHz regardless of any pipewire config.

What I have done so far:
  • In general I have followed the camilladsp-config guide for setting up Alsa loopback as the default system playback device. I had some problems trying to figure out relevant parts and how to modify the instructions to my setup but I think the barebone config is ok. It is working for playback.
  • Using pavucontrol set the MK5 in Pro Audio mode to get the individual input and output channels
  • Create a virtual source for the microphone in pipewire configuration following this example and selected it as the default input device in OS settings
  • Selected in REW the "default (default)" as the output and input devices. The device lists do not contain neither the Alsa loopback nor the virtual source.
  • Monitored the nodes and links using pw-top, pw-mon, Helvum with no apparent reason for not working to together.
  • Countless hours of reading alsa, pipewire, wireplumber and fedora related docs and forum posts to no avail

I can definitely provide heaps of additional info (configs, error messages, screenshots on Helvum etc,) but I thought to first ask if there is larger known issue with this kind of setup.

Any help is well appreciated.
Click to expand...

What might be happening is that when the first program opens the device, a second one cannot access it. Have you tried doing e.g. a loopback measurement with a single program. For example under Windows I use ARTA. This would confirm that the MOTU mk5 can be operated as full duplex (simultaneous read/write) under ALSA.
 
You must log in or register to reply here.
Top Bottom