Hi all, hope somebody can help with some input.
I have made 192kHz measurements in Rew that linearize speaker drivers (four of them), that runs in Camilladsp, problem is that performance is not great. I am running on a AMD A10-7850K on Fedora. Those four filters will in total, demand ~90% CPU on one thread, when playing audio. Sometimes it will hit 100% and have Camilladsp quit/stall. I need to run four more filters, eight in total, for a four way speaker setup. Camilladsp is not doing resampling, that is done in alsa before camilladsp.
One could likely create filters at 96kHz samplerate, and things would be better, but I reckon I am doing something which is very inefficient with my filters, since the CPU load is that high. And that a desktop CPU should have an easy time, running 8x192kHz convolution filters.
I have attached a REW measurement example (subrew.txt, very large filesize) and the derived impulse response exported from REW (in both txt and wav format), which I use directly in camilladsp. The error might be in the last part here as the resolution/information in each file, seems massive and unnecessary.
Are anybody able to help reducing the filters, so that they run more easily and what the best approach would be? I would prefer running Camilladsp at 192kHz.
I tried using rephase to reduce number of taps, but that gives rise to other issues.
Besides the problems I create myself, Camilladsp behaves really nicely.
Kind regards
Michael
I have made 192kHz measurements in Rew that linearize speaker drivers (four of them), that runs in Camilladsp, problem is that performance is not great. I am running on a AMD A10-7850K on Fedora. Those four filters will in total, demand ~90% CPU on one thread, when playing audio. Sometimes it will hit 100% and have Camilladsp quit/stall. I need to run four more filters, eight in total, for a four way speaker setup. Camilladsp is not doing resampling, that is done in alsa before camilladsp.
One could likely create filters at 96kHz samplerate, and things would be better, but I reckon I am doing something which is very inefficient with my filters, since the CPU load is that high. And that a desktop CPU should have an easy time, running 8x192kHz convolution filters.
I have attached a REW measurement example (subrew.txt, very large filesize) and the derived impulse response exported from REW (in both txt and wav format), which I use directly in camilladsp. The error might be in the last part here as the resolution/information in each file, seems massive and unnecessary.
Are anybody able to help reducing the filters, so that they run more easily and what the best approach would be? I would prefer running Camilladsp at 192kHz.
I tried using rephase to reduce number of taps, but that gives rise to other issues.
Besides the problems I create myself, Camilladsp behaves really nicely.
Kind regards
Michael
In alsa by the plug/rate plugin? What resampling method? In general the resampling algorithms used by alsa are quite inefficient, especially the samplerate family. Since the alsa-lib plugins are just a library called by CDSP, their CPU consumption is reported as part of the overall CDSP CPU consumption.
@phofman
With your experience (which I know is vast), if you do not feel 8MB txt raw data (or 4MB wav) times eight is "scary" or extraordinary workload wise, I will not either. But initially, when I saw how heavy it were for Camilladsp to even load the filters, it kind of felt off/they were excessive.
I am not doing anything else than the basic setup shown in asound.conf here, besides using 192kHz sample rate: Cdsp config guide asound.conf Its running fedora on pipewire, I am using pipewire to send all audio to the loopback device, which is the target for camilladsp input.
I did know that I should adjust the quality of the resampling, but I never got to it, so I assume its currently "default", which I remember, as pretty bad (I do not remember exactly where to adjust the setting for resampling, but I will look it up).
With your experience (which I know is vast), if you do not feel 8MB txt raw data (or 4MB wav) times eight is "scary" or extraordinary workload wise, I will not either. But initially, when I saw how heavy it were for Camilladsp to even load the filters, it kind of felt off/they were excessive.
I am not doing anything else than the basic setup shown in asound.conf here, besides using 192kHz sample rate: Cdsp config guide asound.conf Its running fedora on pipewire, I am using pipewire to send all audio to the loopback device, which is the target for camilladsp input.
I did know that I should adjust the quality of the resampling, but I never got to it, so I assume its currently "default", which I remember, as pretty bad (I do not remember exactly where to adjust the setting for resampling, but I will look it up).
Honestly, I do not know the DSP load of CDSP in your setup. But IIUC, your chain is PW -> loopback -> plug plugin -> CDSP. Can you configure PW to do the resampling (it may be better and more economical, being a new project), and avoid the plug plugin completely? PW seems quite flexible in this area https://wiki.archlinux.org/title/PipeWire#Sound_quality_(resampling_quality) .
@Quickmcj I hate to bring this up but the AMD A10-7850K is not a particularly capable CPU and was produced way back in 2014. It is not really up to the task of doing 192kHz FIR audio processing. CDSP processing is floating point intensive. For comparison, a recent Celeron chip, the N5105, can do 8,291 MOps/Sec whereas the A10 can do only 5,502 MOps/Sec. Both have 4 cores. Other factors like I/O may also be much slower on the old hardware.
@Quickmcj the filters are almost 1.2 million points log, that is crazy long! You should not need anywhere near that much (and more than half is just zeroes anyway, they contribute nothing but still eat processing power).
You can cut the filter to a tenth of the size, then things should be much easier.
Something like the marked area here:
I think Rephase can help you do this, and apply some windowing so there is no discontinuiity at the end. Just keep in mind to cut all filters the same way, so you don't make them give different latencies.
You can cut the filter to a tenth of the size, then things should be much easier.
Something like the marked area here:
I think Rephase can help you do this, and apply some windowing so there is no discontinuiity at the end. Just keep in mind to cut all filters the same way, so you don't make them give different latencies.
I should do that for sure yes, first step was getting something playing. I will look more into pipewire, thanks.
Hi @CharlieLaub I know, its running linux on an old htpc, Pi was too difficult to get hold of
(But I imagine the Pi still being weaker, have not looked into it just yet) But as Henrik points out, and this was my suspicion, the filters are way off in design, I need to trim them down, so I will start there, thanks for commenting.Hi Henrik
I did try Rephase for exactly this, to reduce the number of taps in some thoughtful manner, but I learned that rephase cant actually do that. It will import measurements from REW, but it will do zero with them, only show them, apparently. So all exports from Rephase result in flat magnitude and phase, as I did not adjust anything in rephase at all. I will try to see if I can apply a window in REW before export.
The suspicion were exactly what you point out, I just did not have adequate knowledge about the subject to be sure.
I had trouble creating 192kHz convolution filters for camilladsp based of inverted speaker driver measurements, which would not shift in frequency range when applied, so I might have gotten of the wrong track at some point trying to find a solution.
Many thanks for the reply, this should be the last hurdle before great sound.
Edit: Think I found it, hidden in plain sight (See attachments and the reduction in data points) Again thanks for leading me in the right direction, Camilladsp is much more happy now that I do not bog it down, now running four filters at 18% load.
Attachments
Last edited:
Henrik, several things.
1. REW has been enhanced to output CamillaDSP IIR (Biquad) filters and Pipeline entries in the same format as your python script,
https://www.avnirvana.com/threads/camilladsp-iir-format-output.11060/
I suggest that you modify your Github documentation -
"Translating filters exported by REW
REW can automatically generate a set of filters for correcting the response. These can then be exported as an .xml-file. This file can then be translated to CamillaDSP filters using the translate_rew_xml.py Python script. This will generate filters and pipeline steps that can be pasted into a CamillaDSP config file. This script currently supports only Peaking filters. "
to something like :
REW generated Biquad filters.
REW can automatically generate a set of filters for correcting the response.
In REW Preferences, Equaliser, if the Default equaliser Manufacturer drop down is set to CamillaDSP then when in the EQ Filters screen there is in the Filter Task section the option of "Save filter settings to YAML file".
Selecting this option causes a popup box asking "Enter the label to use for each filter, the filter number will be appended to the label". This allows identification of the filter set. The generated YAML file will contain filters and pipeline steps that can be pasted into a CamillaDSP config file.
2. The CamillaDSP option to group filters in the pipeline display.
My original request was "The pipeline plot could optionally "group" biquads with the same name less the _nn suffix, reducing a potential 17 boxes to 1 box for the plot." https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7106214
I wonder if this could be added as an extra option. The reason being that a filter section (in my case) for each channel contains a Volume filter, FIR filter for xover and phase manipulation, gain filter, delay filter, sometimes a phase invert filter and a bunch of biquad filters. If the only the biquads were grouped it would make it easier to visualise the filter sequence.
3. A suggestion for a new filter that could perform Dynamic range control, kind of a software version of a dbx Model 3BX ( https://dbxpro.com/en/product_documents/dbx_3bx-ds_manualpdf ) , read from page 6 about Expansion, Compression, Impact Recovery and Ambience.
1. REW has been enhanced to output CamillaDSP IIR (Biquad) filters and Pipeline entries in the same format as your python script,
https://www.avnirvana.com/threads/camilladsp-iir-format-output.11060/
I suggest that you modify your Github documentation -
"Translating filters exported by REW
REW can automatically generate a set of filters for correcting the response. These can then be exported as an .xml-file. This file can then be translated to CamillaDSP filters using the translate_rew_xml.py Python script. This will generate filters and pipeline steps that can be pasted into a CamillaDSP config file. This script currently supports only Peaking filters. "
to something like :
REW generated Biquad filters.
REW can automatically generate a set of filters for correcting the response.
In REW Preferences, Equaliser, if the Default equaliser Manufacturer drop down is set to CamillaDSP then when in the EQ Filters screen there is in the Filter Task section the option of "Save filter settings to YAML file".
Selecting this option causes a popup box asking "Enter the label to use for each filter, the filter number will be appended to the label". This allows identification of the filter set. The generated YAML file will contain filters and pipeline steps that can be pasted into a CamillaDSP config file.
2. The CamillaDSP option to group filters in the pipeline display.
My original request was "The pipeline plot could optionally "group" biquads with the same name less the _nn suffix, reducing a potential 17 boxes to 1 box for the plot." https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7106214
I wonder if this could be added as an extra option. The reason being that a filter section (in my case) for each channel contains a Volume filter, FIR filter for xover and phase manipulation, gain filter, delay filter, sometimes a phase invert filter and a bunch of biquad filters. If the only the biquads were grouped it would make it easier to visualise the filter sequence.
3. A suggestion for a new filter that could perform Dynamic range control, kind of a software version of a dbx Model 3BX ( https://dbxpro.com/en/product_documents/dbx_3bx-ds_manualpdf ) , read from page 6 about Expansion, Compression, Impact Recovery and Ambience.
Thanks!
Would you perhaps know if there is a log of terminated apps by this very function?
//
Thanks for the updated text! I had this on my list of things to do before releasing 2.0.
This would be quite a large amount of work for a feature I'm not convinced is generally useful. It would depend on filters being named in a very specific way, and in cases when they are not it would often group filters in unexpected ways.
Can't you just put all the "something_nn" biquads in a separate filter step? That would work fine with the existing plot, and would also be easier to overview in the pipeline editor.
Compression is done, it will be included in 2.0. I didn't look at expansion but that could also be interesting. That can probably borrow large parts from the compressor code. The Impact Recovery isn't very well described so not quite sure how that is actually working. It's probably based on the compressor somehow. If you know of a better description somewhere I'd be happy to take a look.
Ambience seems to be quite different from the other functions. It appears to be variant of stereo expansion. That can already be implemented by combining mixers and existing filters.
Henrik, thank you for your patient polite reply.
Of course I can (and now have) put all the "something_nn" biquads in a separate filter step, I just had not thought of something so obvious !
It is indeed easier to overview in the pipeline editor and works fine with the existing plot.
Hello,
i just notice that the Linux program EasyEffects lets you choose between IIR and FIR processing, is there any chance that we can create FIR filters directly in camillaDSP without needing to create a Convolution file in the future?
and how you guys create FIR Convolution files? i try to find a easy solution, maybe a program that i can just input the parametric eq settings which creates a Convolution File based of it?
i just notice that the Linux program EasyEffects lets you choose between IIR and FIR processing, is there any chance that we can create FIR filters directly in camillaDSP without needing to create a Convolution file in the future?
and how you guys create FIR Convolution files? i try to find a easy solution, maybe a program that i can just input the parametric eq settings which creates a Convolution File based of it?
unsure what you mean by "proper fir filter generation" but i was thinking of something EasyEffects does, which lets you simply create parametric filters with FIR generation instead of IIR
in this case, if im not wrong, filters would have linear non distorted phase but the same amplitude change
tho "proper fir filter generation" probably means correcting the speaker itself too, which would be still just possible with rePhase
I guess what proper fir generation means depends a lot on who you ask. For me, at a bare minimum it must include control over, length, windowing and centering. Without this, I would consider it too limited to be of any real use.
Phase correction is a separate issue. But for most corrections, the problem you want to fix exists in both amplitude and phase. A linear phase correction will obviously not do anything about the phase. On the other hand, many problems you want to fix are minimum phase. This means that a minimum phase correction (meaning an iir filter) can fix both amplitude and phase.
Phase correction is a separate issue. But for most corrections, the problem you want to fix exists in both amplitude and phase. A linear phase correction will obviously not do anything about the phase. On the other hand, many problems you want to fix are minimum phase. This means that a minimum phase correction (meaning an iir filter) can fix both amplitude and phase.