@DEQ+TheEnd try this command:
That should start it without a config, in wait mode. After a second or so it should create the statefile. Then you can just stop it with ctrl-c../camilladsp -s statefile.yml -p1234 -w
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...
//
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?
//
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.Perhaps the standard horizontal range could be 15-25k in order to look a bit beyond the standard 20-20k?
EDIT: Actually one can pinch the freq bar and zoom in to above 80kHz
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:

expanded:

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

expanded:

@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:
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.
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
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!
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!
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:
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?
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?
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!
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....
//
//
Yes and no...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?
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....
//
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....
//
Yes and no...
Thank you for the links and the post, very helpful!
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.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....
//
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.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...
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?Or like for Capture, associated function tabs for Upsampling, but for Output....
//
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...
//
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...
//
- Home
- Source & Line
- PC Based
- CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc