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

Yes that seems complicated. I was thinking about rePhase and its phase equaliser.... (it dosen't use GD as input).

Re: auto scaled...

My observations...
  • the FR scale starts at 1Hz - seldom one need to bother about this - makes the less focus what matters (20-20k?), 1-20Hz takes 33% of view...
  • GD is way to zoomed in - I think the least we hear is about 0,1ms? But it is good that 0 is offset to level as otherwise it gets cluttered.
  • Perhaps a "rule" would be try to fill, for all three types, the space vertically with say about 33% and let scale follow that graphical utilisation of space - in this case below it would mean that DG shrinks and phase expands considerable but level expands just some.
  • Perhaps the standard horizontal range could be 15-25k in order to look a bit beyond the standard 20-20k?

gentl.jpg


//
 
TNT said:
Perhaps the standard horizontal range could be 15-25k in order to look a bit beyond the standard 20-20k?
Click to expand...
If you drag the frequency bar at the bottom it seem to go to approx 50kHz in V1. Not sure if the actual calculation does? But yeah, nice if one could see full bandwitch for 48kHz capture by default.

1698848861809.png



EDIT: Actually one can pinch the freq bar and zoom in to above 80kHz
1698849459487.png
 
Last edited:
I know that is possible to change - but it gets a bit tiresome change if you have a lot and do many changes...

//
 
I tweaked the scale settings a bit so the group delay doesn't zoom to less than +- 0.1 ms, and set the default frequency scale to 10-20k. Letting it start at 20 Hz makes the tick marks uglier (and 15 is worse) and it's similar at the upper limit. 25 or 30 kHz doesn't turn out great. It's easy to get any given range look good for a static plot, but here things are dynamic. The logic must create a scale with ticks that work well at every possible zoom level.

Same filter as @TNT posted above, with the new defaults, normal size:

Screenshot 2023-11-02 at 22.10.21.png

expanded:
Screenshot 2023-11-02 at 22.22.28.png
 
@HenrikEnquist - I've been getting extra characters or lines attached to the end of the statefile. Sometimes it would be a few blank lines which don't cause a problem, but for example after activating then deactivating the Dim button in the GUI I would get a zero appended to the end which generates an error when CamillaDSP tries to load it:
Code: 
---
config_path: /home/streamer/camilladsp/configs/crossfeed-dt770pro-mid.yml
mute:
  - false
  - false
  - false
  - false
  - false
volume:
  - 0.0
  - 0.0
  - 0.0
  - 0.0
  - 0.0
0
It turns out the problem occurs when the new statefile is shorter than the old one, and the new file would have the tail end of the old file tagged on to the end. Adding truncate(true) to the OpenOpens when the statefile is written fixes this. I've submitted a PR.
 
Dear All,
As a very rookie person, may I ask for your kind opinion, what shall I do to test CamillaDSP on Mac Studio M1 Max (base model) with an UAD ApolloX6?
just would like to know if I get better results on my stereo studio monitor speakers with measured room acoustics and carefully created IR... compared to SW SoundID solution.

Code:

devices:
adjust_period: 10
capture:
channels: 2
device: BlackHole 2ch
format: FLOAT32LE
type: CoreAudio
capture_samplerate: 48000
chunksize: 4096
enable_rate_adjust: true
playback:
channels: 2
device: Universal Audio Thunderbolt
exclusive: false
format: FLOAT32LE
type: CoreAudio
queuelimit: 4
rate_measure_interval: 1
samplerate: 48000
silence_threshold: -100
silence_timeout: 5
stop_on_rate_change: false
target_level: 0
filters:
FIR:
type: Conv
parameters:
type: Wav
filename: coeffs/LR-final-MP-48k.wav
pipeline:
- channel: 0
names:
- FIR
type: Filter
- channel: 1
names:
- FIR
type: Filter

Error:
% /Users/studio/camilladsp /Users/studio/configs/config.yml -p1234
2023-11-09 22:42:10.517275 INFO [src/bin.rs:683] CamillaDSP version 2.0.0-alpha5
2023-11-09 22:42:10.517341 INFO [src/bin.rs:684] Running on macos, x86_64
2023-11-09 22:42:10.607464 INFO [src/coreaudiodevice.rs:1163] The capture device supports pitch control
2023-11-09 22:42:10.609544 ERROR [src/bin.rs:286] Playback error: Failed to find matching physical playback format
2023-11-09 22:42:10.635405 INFO [src/processing.rs:37] Playback thread has already stopped.

Audio Device:
Universal Audio Thunderbolt:
Default Input Device: Yes
Default Output Device: Yes
Default System Output Device: Yes
Input Channels: 32
Manufacturer: Universal Audio, Inc.
Output Channels: 34
Current SampleRate: 48000
Transport: PCI
Input Source: Default
Output Source: Default

Thank you very much for any feedback in advance!
 
It fails because it tries setting the playback format to 32-bit float, that the dac doesn't support. I would suggest just removing the "format: FLOAT32LE" parameter from the playback section. The it will leave the format setting of the dac unchanged.
 
Hey all, I had some beginner CamillaDSP questions and I was hoping someone could point me in the right direction. I was hoping to do some room correction for my setup which currently uses Logitech Media Server -> Raspberry pi -> Stereo. I'm using PiCorePlayer on the Pi and I found this project to install CamillaDSP on there:

https://github.com/JWahle/piCoreCDSP

I've got that working, but now I'm trying to generate my "filters." I can measure with REW, and I've got the latest beta version that has CamillaDSP as an EQ option. My question is, is that the right approach? After I make my measurement do I want to head to the EQ window, generate a filter, and "save filter settings to YAML file"?

It looks like this would just create a parametric EQ setup, is that right? Is this the preferred method? Do I take the filters from the yaml files and put them into the CamillaDSP webui?

Thanks in advance! Would love links to more reading if I'm misunderstanding things!
 
You are on the rigth way. Quicker is to edit in the content of the REW generated filters. Be vary of any spaces / indentation as yaml is sensitive to that.

//
 
When I do this, I get a bunch of Biquad filters:

Code: 
  filterL_1:
    parameters:
      freq: 71.2
      gain: -9.6
      q: 2.0
      type: Peaking
    type: Biquad
  filterL_2:
    parameters:
      freq: 273.0
      gain: -11.8
      q: 3.2
      type: Peaking
    type: Biquad

Now, I have been doing a bunch of reading that's way over my head and I read something about Biquads being limited to certain sample rates? Are the filters generated here only for audio played back at the same sample rate?
 
AssistantSalmon said:
Hey all, I had some beginner CamillaDSP questions and I was hoping someone could point me in the right direction. I was hoping to do some room correction for my setup which currently uses Logitech Media Server -> Raspberry pi -> Stereo. I'm using PiCorePlayer on the Pi and I found this project to install CamillaDSP on there:

https://github.com/JWahle/piCoreCDSP

I've got that working, but now I'm trying to generate my "filters." I can measure with REW, and I've got the latest beta version that has CamillaDSP as an EQ option. My question is, is that the right approach? After I make my measurement do I want to head to the EQ window, generate a filter, and "save filter settings to YAML file"?

It looks like this would just create a parametric EQ setup, is that right? Is this the preferred method? Do I take the filters from the yaml files and put them into the CamillaDSP webui?

Thanks in advance! Would love links to more reading if I'm misunderstanding things!
Click to expand...

Here is some reading for you - https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7213813
 
Suggestion: Filter tab; make the left part of the window (Apply, DSP load, VU meters etc) stay visible while one scroll down among the filters? As of now one need to chase the Apply button as one try out different settings for a filter....

//
 
AssistantSalmon said:
Now, I have been doing a bunch of reading that's way over my head and I read something about Biquads being limited to certain sample rates? Are the filters generated here only for audio played back at the same sample rate?
Click to expand...
Yes and no...

A "biquad" is simply the ratio of two quadratic functions (polynomials of order 2). These links will provide some background and you can see the biquad transfer function at the top of the page:
https://en.wikipedia.org/wiki/Electronic_filter_topology#Biquad_filter_topology
https://en.wikipedia.org/wiki/Digital_biquad_filter
A biquad is a second order approximation to a brick wall filter, this approximation being created through the process of (1) assuming the filter must take the form of one function divided by another (also known as a rational function approximation), (2) assuming that these two functions can be expressed as a power series (a polynomial) and then (3) truncating the order of the approximation to 2. This is standard math stuff.

Certain formulas are used to calculate the transfer function of a filter expressed as a biquad from its transfer function coefficients (a0, a1, a2, b0, b1, and b2). It is these coefficients that are sample rate dependent. Another way to say it is that the exact same filter response has one set of coefficients for one sample rate, and another totally different set of coefficients for another sample rate.

If you specify a "biquad" by these coefficients directly then the filter response calculation will only be valid for the sample rate used to generate the coefficients. Thus, your biquad is sample rate dependent. For example, miniDSP has an "advanced biquad" mode where you specify the coefficients directly.

On the other hand, in CamillaDSP and other software DSP progams, when you specify the filter by its parameters (e.g. frequency, Q, etc.) the software uses these to calculate the transfer function coefficients for whatever sample rate is currently being used. As soon as the sample rate changes to a new one, the software re-calculates all of the TF coefficients so that the filter response remains constant.
 
Last edited:
Upsampling as a filter please!?

I would like to hook up a player on 44,1 to Capture with Resampling = none. Do CDSP filtering processing on 44,1 and then, as last stage, just before output, do Upsample to e.g. 192ksps...

Or like for Capture, associated function tabs for Upsampling, but for Output....

//
 
TNT said:
Suggestion: Filter tab; make the left part of the window (Apply, DSP load, VU meters etc) stay visible while one scroll down among the filters? As of now one need to chase the Apply button as one try out different settings for a filter....

//
Click to expand...
I have thought of this too, basically making the filter list a scrollable field so that the sidebar and the tabs at the top always stay in view. I will probably fix that next time I do some changes to the layout.

TNT said:
Upsampling as a filter please!?

I would like to hook up a player on 44,1 to Capture with Resampling = none. Do CDSP filtering processing on 44,1 and then, as last stage, just before output, do Upsample to e.g. 192ksps...
Click to expand...
Resampling can't be implemented as a filter. That's because the sample rate must remain constant all the way through the pipeline, and there are many good reasons for keeping it this way.
TNT said:
Or like for Capture, associated function tabs for Upsampling, but for Output....

//
Click to expand...
This could be done. The question here is more if it's worth the extra work, and pretty large increase in complexity. What's the reason you can't do the processing at 192k?
 
1+2 Ok.

Well, I suppose one could save 4x computing of not have to run all filters and convolution at 192 but att 44. The reason for wanting 192 is to ease the impact of low Fs reconstruction filter in following DAC. What remains ro be done at 192 is only the upsampling...

//
 
You must log in or register to reply here.
Back
Top