had to put it in a zip because it was too long for the txt attachment. Let me know if that works/doesn't.
I did try building with 32bit options this go round, but I'd go back o 64 bit if it made a difference. (I'm on a pi 4, latest raspbian with an updated kernel)
thanks!
Thanks! Looking at your log, I would say that the new code to avoid the blocking read is causing this. I'll put in a setting for that and let the default be the old behavior.
Once that's done, there will be another beta release to make sure it works, then I hope I can release the final 0.5.0.
BTW the next beta will have SSE acceleration included! That should be about twice as fast on Atoms, Pentiums and Celerons.
And convolution should also be some 10-20% faster on arm.
Once that's done, there will be another beta release to make sure it works, then I hope I can release the final 0.5.0.
BTW the next beta will have SSE acceleration included! That should be about twice as fast on Atoms, Pentiums and Celerons.
And convolution should also be some 10-20% faster on arm.
New beta here: Release v0.5.0-beta6 * HEnquist/camilladsp * GitHub
This version adds a new option to optionally avoid the blocking read of Alsa. This hopefully fixes the problem jrubins found.
Also, the new version of RustFFT with SSE4.1 support was released yesterday. This should give an up to 2x speed increase for convolution and synchronous resampling on x86_64 cpus that have SSE4.1 and not AVX, like Atoms, Celerons and Pentiums. For Arm, it will be some 10-20% faster due to some general optimizations.
This version adds a new option to optionally avoid the blocking read of Alsa. This hopefully fixes the problem jrubins found.
Also, the new version of RustFFT with SSE4.1 support was released yesterday. This should give an up to 2x speed increase for convolution and synchronous resampling on x86_64 cpus that have SSE4.1 and not AVX, like Atoms, Celerons and Pentiums. For Arm, it will be some 10-20% faster due to some general optimizations.
It's just a new config option on the capture device, see here:
GitHub - HEnquist/camilladsp at develop
The default to use the old mode, so you don't need to change your config.
GitHub - HEnquist/camilladsp at develop
The default to use the old mode, so you don't need to change your config.
Suggested change for headphone calibration
Hi Henrik and CamillaDSP community,
I really appreciate your great work with CamillaDSP. Tack så mycket!
Since your library is so comprehensive and fleksible, I think (and hope) that it
will become a unifying standard in open source DSP. Moode Player has
already adapted it, and I hope that others will follow soon.
You are probably already aware of the work being done with regard to headphone
EQ (calibration), where it has become the new trend to calibrate your headphones
in order to get a perfect frequency response.
More on this here:
GitHub - jaakkopasanen/AutoEq: Automatic headphone equalization from frequency responses
and here:
oratory1990 - for questions about acoustics
As you can see from the following (below), EQ tables for headphones are often
specified with peaking, low_shelf and high_shelf specifications. Unfortunately
the shelf filters are often shown with the parameters Frequency, Gain and
Q value, which makes it difficult to use CamillaDSP, since Q values are not
supported i high/low shelf filters.
An example (not my headphones or submission)
CamillaDSP IIR filters : oratory1990
CamillaDSP Config example for Beyerdynamics DT 770 Pro * GitHub
Example headphone EQ presets:
index/list_of_presets - oratory1990
and here (one of the more popular headphones):
https://www.dropbox.com/s/r7wa83eb53da6fh/Audio Technica ATH-M50x.pdf?dl=0
So I would hear if you would consider to make an ekstra high_shelf/low_shelf
filter, that accepts the Q parameter instead of the Slope parameter.
As far as I can see (I am no expert), from:
https://www.musicdsp.org/en/latest/_downloads/3e1dc886e7849251d6747b194d482272/Audio-EQ-Cookbook.txt
that would entail to make (something like) the following changes in new copies of
the functions config::BiquadParameters::Highshelf, and
config::BiquadParameters::Lowshelf (in biquad.rs)
Old line:
let alpha = sn / 2.0 * ((ampl + 1.0 / ampl) * (1.0 / (slope / 12.0) - 1.0) + 2.0).sqrt();
New line (Q is the new parameter):
let alpha = sn / (2.0 * Q);
I don't know if that is correct, or if you think it is a good idea, but it
would make life easier for headphone enthusiasts
Any way, changes or not, CamillaDSP is definitely still a great thing, also
for headphone calibration!
Best regards
Jens
Hi Henrik and CamillaDSP community,
I really appreciate your great work with CamillaDSP. Tack så mycket!
Since your library is so comprehensive and fleksible, I think (and hope) that it
will become a unifying standard in open source DSP. Moode Player has
already adapted it, and I hope that others will follow soon.
You are probably already aware of the work being done with regard to headphone
EQ (calibration), where it has become the new trend to calibrate your headphones
in order to get a perfect frequency response.
GitHub - jaakkopasanen/AutoEq: Automatic headphone equalization from frequency responses
and here:
oratory1990 - for questions about acoustics
As you can see from the following (below), EQ tables for headphones are often
specified with peaking, low_shelf and high_shelf specifications. Unfortunately
the shelf filters are often shown with the parameters Frequency, Gain and
Q value, which makes it difficult to use CamillaDSP, since Q values are not
supported i high/low shelf filters.
An example (not my headphones or submission)
CamillaDSP IIR filters : oratory1990
CamillaDSP Config example for Beyerdynamics DT 770 Pro * GitHub
Example headphone EQ presets:
index/list_of_presets - oratory1990
and here (one of the more popular headphones):
https://www.dropbox.com/s/r7wa83eb53da6fh/Audio Technica ATH-M50x.pdf?dl=0
So I would hear if you would consider to make an ekstra high_shelf/low_shelf
filter, that accepts the Q parameter instead of the Slope parameter.
As far as I can see (I am no expert), from:
https://www.musicdsp.org/en/latest/_downloads/3e1dc886e7849251d6747b194d482272/Audio-EQ-Cookbook.txt
that would entail to make (something like) the following changes in new copies of
the functions config::BiquadParameters::Highshelf, and
config::BiquadParameters::Lowshelf (in biquad.rs)
Old line:
let alpha = sn / 2.0 * ((ampl + 1.0 / ampl) * (1.0 / (slope / 12.0) - 1.0) + 2.0).sqrt();
New line (Q is the new parameter):
let alpha = sn / (2.0 * Q);
I don't know if that is correct, or if you think it is a good idea, but it
would make life easier for headphone enthusiasts
Any way, changes or not, CamillaDSP is definitely still a great thing, also
for headphone calibration!
Best regards
Jens
The chances are unfortunately quite small. To do this with decent performance, all the processing would have to be done in the camilladsp process. This would add quite a bit of complexity, and increase cpu usage. And that goes against my goal of keeping the dsp engine slim.
So there are several ways to define 2nd order filters. The most common for shelves are Q and Slope, but I have seen Bandwidth as well. And there are probably other ways in use somewhere as well.
Instead of supporting all that, I have chosen to limit so there is a single way to define each filter type. This makes it much easier to avoid bugs, and I really prefer to keep it like this. All filter types must be supported by camilladsp, the gui, and the pycamilladsp-plot library, so there are plenty of opportunities for bugs to sneak in.
The Audio EQ cookbook gives a simple formula for going from slope to Q:
Code:
1/Q = sqrt((A + 1/A)*(1/S - 1) + 2)
Code:
S = slope/12
A = 10^(gain/40)I get this (unverified!):
Code:
slope = 12/((1/Q^2 - 2.0)/(A + 1/A) + 1.0)Hi Henrik,
Thanks for the very quick reply!
I completely understand the desire to keep it complete and simple, - and that is probably also why CamillaDSP has so much traction at the moment.
I am, for my part, just happy that you are doing what you doing.
I just hope, that someone would consider making a CamillaDSP preprocessor, that could enhance some of the filter definitions, add variables and arithmetic expression expressions, etc. and then "compile" it to basic CamillaDSP config files. Well, just an idea, anyway.
Best regards
Jens
That is understandable and makes sense. How about an alternative like writing to an alternate target, tee or file so the results could be post processed / analyzed in another program ? It would be a good way to document the filter results even if it is just a snapshot in time.
Can CamillaDSP currently write N-channels to a file ?
It can write any number of channels to a raw file. Just not at the same time as when outputting to for example an Alsa device.
That seems like a reasonable idea, and could be fun to write. I will probably never find the time, but maybe someone else wants to try? Then I would suggest to use Python with PyYAML: https://pyyaml.org/wiki/PyYAMLDocumentation
For arithmetic expressions etc, check out pyparsing:
Welcome to PyParsing’s documentation! — PyParsing 3.0.0b2 documentation
Now that everything is fully functional again (thanks Henrik!!), I can get back to feature requests/bugs/questions
I'm still having trouble with free biquads. When I go to biquad designer that you reference in your code, I'm still not getting the same output (visually) that I would expect.
No filter where I put in a1, a2, b0, b1, b2 looks anything like I expect it to. That could be because the visualization is not working as intended, or because the biquad engine isn't, or (this does seem probable) I'm doing something wrong
Take a look at the attached screenshots and let me know if there's something incorrect. When I do an FIR filter for RIAA correction, it looks spot-on, BTW. Other biquads like low shelf and crossover curves also look correct. Just something with "free" biquads.
feature requests:
you can select a remote file when you choose an FIR filter, but not for the configuration. Would be a lot cooler if you could
Would love to be able to add filters/mixers above or below on the pipeline. That way it's easy to add things before some other thing.
A question: can I upload FIR filters as WAV or FLAC files as well as text? It seems like I can given the options of "format" but I just wanted to check
Finally, a compliment: this is a really well-executed DSP tool and seems to do a really nice job. Thanks!
I'm still having trouble with free biquads. When I go to biquad designer that you reference in your code, I'm still not getting the same output (visually) that I would expect.
No filter where I put in a1, a2, b0, b1, b2 looks anything like I expect it to. That could be because the visualization is not working as intended, or because the biquad engine isn't, or (this does seem probable) I'm doing something wrong
Take a look at the attached screenshots and let me know if there's something incorrect. When I do an FIR filter for RIAA correction, it looks spot-on, BTW. Other biquads like low shelf and crossover curves also look correct. Just something with "free" biquads.
feature requests:
you can select a remote file when you choose an FIR filter, but not for the configuration. Would be a lot cooler if you could
Would love to be able to add filters/mixers above or below on the pipeline. That way it's easy to add things before some other thing.
A question: can I upload FIR filters as WAV or FLAC files as well as text? It seems like I can given the options of "format" but I just wanted to check
Finally, a compliment: this is a really well-executed DSP tool and seems to do a really nice job. Thanks!
Attachments
Thanks! Then I will release this version as final 0.5.0.
The data structure that stores the filter configs doesn't guarantee to preserve the order, for performance reasons I suppose. Best we can do is to sort alphabetically, then it at least becomes predictable.
There seems to be some bug in the plotting, I'll look at it.
You can use this in the meanwhile (if you swap a and b):
Filter frequency response grapher | EarLevel Engineering
Both of these are already done and will be available in the next gui release!feature requests:
you can select a remote file when you choose an FIR filter, but not for the configuration. Would be a lot cooler if you could
Would love to be able to add filters/mixers above or below on the pipeline. That way it's easy to add things before some other thing.
FLAC (or any other compressed format) isn't supported. WAV kindof is, since you can read the audio data inside as raw data. The new gui will have some logic to help out with the settings for that, but only for single-channels wav files. I will add proper reading of wav for coefficient files in the next camilladsp version.
Thanks!
Hi Henrik, yesterday I tried to install CamillaDSP on a fresh install of minimal Debian. I cloned the git repository and tried to compile. I installed the missing packages that the compile process reported during compilation and I was able to make it to 2 or 3 steps before the last one (something like 138 of 141). It reported two errors with numbers (I forgot to take a picture, I thought I did). One of them was reporting some wrong use of function and the other one something with nightly build of rust and some suggestion to fix it. I am just a slightly advanced Linux noob, but I have already used git and compiled successfully a few programs with the help of google. Could it be that some packages are too new to compile? Do you have any idea what might be wrong? Tonight, I think I will try to install the latest precompiled beta instead. It is a HP T510 thin client that I plan to use as an AirPlay receiver, experimenting with DRC and later also with 2x4 crossover.
Edit: I think it is the same error as in this post: https://www.diyaudio.com/forums/pc-...rossovers-correction-etc-130.html#post6400206
I need to update rust, since it will still be an old version in the repository.
Edit: I think it is the same error as in this post: https://www.diyaudio.com/forums/pc-...rossovers-correction-etc-130.html#post6400206
I need to update rust, since it will still be an old version in the repository.
Last edited: