I'm currently using this software to apply eq's, delay, etc.
But I plan on using it for FIR instead of EQ and also crossover. Initially 4 channel crossover (2 above 150Hz and 2 below 150Hz, then I might get a new amp to feed the two channel full range speakers as they provide independant banana inputs).
So I might be doing 6 channel of audio with FIR, delay compensation, etc, etc...
For now, I use one of my laptop who rely on a 7th gen i7. (7820HQ at 2.9Ghz, it's old now, but still rocking for my dev work)
The cpu usage is about 5%, and when I try FIR in stereo, it goes up to 20% per channel, according to the provided usage by EqAPO.
That measure is provided with the mention "one core".
So I want to know, how is the parrallelism/multithreading implemented in this software ?
Will I take benefits of more core ? If so, how is it scaled ? Is it a "per channel" core attribution ?
Or should I go for biggest computational power per core if the solution runs only on a single core ?
I plan on getting a NUC to have a silent machine that is my main source in my office I plan on re-purposing as a listening room with acoustical treatment etc.
So yeah, what's the scaling strategy used by this software ?
And, based on that, what should be the spec I look after ? More core ? More powerfull cores ? Or anything else.
Thank you in advance for you time and your answers.
(and, to the dev(s), keep up the great work, your solution is amazing)
(Also, run this on windows 10, up to date, might matter)
(And yeah, I could just dig in the code and figure it out myself, but come on, we're devs, who wants to put the efforts in when there's easier solutions... not like we get paid for our efforts... will also create general knowledge and all I have to do is listening and concentrating to my favourite music instead of reading code that would certainly lead me to going crazy about how it's implemented. Cause we're all the same, we don't like code other than ours. Let's be real for a moment.)
Last edit: Manu404 2024-07-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you decide to use IIR filters, remember keep the filter order low (use 1st or 2nd order filters) because of the target of the combined (sum) response of LPF and HPF is flat ( zero phase and zero gain).
LR4 and 4th order Butterworth filters seems to result bad sum response when crossover frequency is low (as your 150Hz) and it gets worse with higher sample rates.
As being an Audio Processing Object (APO) I don't think Equalizer APO can be multithreading. Certainly a channel per core isn't possible. In principle an APO can't be scaled in the way you're describing it. Btw. The developer isn't very active so don't expect an answer on this any time soon.
Anyway, I don't get the high CPU usage. When using the biquad filters for instance the CPU usage is in the nanoseconds. Perhaps on older CPU's it's a few 100 hundreds of ns. Well, unless you have hundreds or thousands of filters. Of course convolution (is this FIR?) or graphic eq as Equalizer APO calls it, is much slower. When using the Configuration Editor as Equalizer APO interface this is the standard way of EQ-ing. It's nice and fast enough but way slower than biquads filters. And perhaps that's the issue of your immense high CPU usage although it can't be measure per audio channel as you're mentioning. Of course it can be measured per core. And of course the audio delay can measured per channel.
Btw. What Equalizer APO does is getting the audio stream (after rerouting by its Configurator) and performing on it according the actions as stated in config.txt. As such the delay is in principle an amount of audio samples.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think Equalizer APO can be multithreading. Certainly a channel per core isn't possible.
There is nothing stopping an APO from creating its own internal threads and then distributing work over them. EAPO doesn't do that, though.
Of course convolution (is this FIR?) or graphic eq as Equalizer APO calls it
Convolution/FIR and "graphic eq" aren't the same thing.
Convolution filters can be quite expensive if the filter is long (many taps). For example, DRC-FIR generates huge 65k-tap filters by default - if one were to filter all 8 channels of a 7.1 setup with 65k taps per channel, the CPU usage can definitely become a problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Convolution/FIR and "graphic eq" aren't the same thing.
I'm under the impression that the GraphicEQ command of Equalizer APO uses convolution by creating an internal impulse response "file". But I'm a noob on these things. Anyway, the source code suggests that convolution is used. For instance. the process methods of GraphicEQ and convolution are identical.
if one were to filter all 8 channels of a 7.1 setup with 65k taps per channel, the CPU usage can definitely become a problem.
That begs the question of why using such elaborate filters. A bit overkill?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm under the impression that the GraphicEQ command of Equalizer APO uses convolution
Sure. I was just clarifying that one can use convolution without using GraphicEQ, by supplying their own filters (impulse responses).
That begs the question of why using such elaborate filters. A bit overkill?
Long filters are necessary for high accuracy in the bass region. Clever calibration packages will combine IIR filters in low frequencies (for computational efficiency) with FIR filters in high frequencies (for higher precision and flexible phase response) to give the best of both worlds, but these combined filters are more complicated to design.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks again. I think the command name 'GraphicEQ' isn't the best naming giving. Probably used because how it's presented in the Configuration Editor. I rather would call the command 'ConvolutionEQ' or something.
So when combining all kinds of filters explains the heavy CPU usage. If one wants precision the necessity for a fast computer arises.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see these enabled (in .vcxproj)
<optimization>MaxSpeed</optimization>
<intrinsicfunctions>true</intrinsicfunctions>
<multiprocessorcompilation>true</multiprocessorcompilation>
Dunno what these actually results to in MSVC world (been using only GCC and Clang last few years (in Ubuntu)). With VC++ own tools one could check this.
"Directory change notification" runs in its own thread (FilterEngine class, IIRC).
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm currently using this software to apply eq's, delay, etc.
But I plan on using it for FIR instead of EQ and also crossover. Initially 4 channel crossover (2 above 150Hz and 2 below 150Hz, then I might get a new amp to feed the two channel full range speakers as they provide independant banana inputs).
So I might be doing 6 channel of audio with FIR, delay compensation, etc, etc...
For now, I use one of my laptop who rely on a 7th gen i7. (7820HQ at 2.9Ghz, it's old now, but still rocking for my dev work)
The cpu usage is about 5%, and when I try FIR in stereo, it goes up to 20% per channel, according to the provided usage by EqAPO.
That measure is provided with the mention "one core".
So I want to know, how is the parrallelism/multithreading implemented in this software ?
Will I take benefits of more core ? If so, how is it scaled ? Is it a "per channel" core attribution ?
Or should I go for biggest computational power per core if the solution runs only on a single core ?
I plan on getting a NUC to have a silent machine that is my main source in my office I plan on re-purposing as a listening room with acoustical treatment etc.
So yeah, what's the scaling strategy used by this software ?
And, based on that, what should be the spec I look after ? More core ? More powerfull cores ? Or anything else.
Thank you in advance for you time and your answers.
(and, to the dev(s), keep up the great work, your solution is amazing)
(Also, run this on windows 10, up to date, might matter)
(And yeah, I could just dig in the code and figure it out myself, but come on, we're devs, who wants to put the efforts in when there's easier solutions... not like we get paid for our efforts... will also create general knowledge and all I have to do is listening and concentrating to my favourite music instead of reading code that would certainly lead me to going crazy about how it's implemented. Cause we're all the same, we don't like code other than ours. Let's be real for a moment.)
Last edit: Manu404 2024-07-29
If you decide to use IIR filters, remember keep the filter order low (use 1st or 2nd order filters) because of the target of the combined (sum) response of LPF and HPF is flat ( zero phase and zero gain).
LR4 and 4th order Butterworth filters seems to result bad sum response when crossover frequency is low (as your 150Hz) and it gets worse with higher sample rates.
As being an Audio Processing Object (APO) I don't think Equalizer APO can be multithreading. Certainly a channel per core isn't possible. In principle an APO can't be scaled in the way you're describing it. Btw. The developer isn't very active so don't expect an answer on this any time soon.
Anyway, I don't get the high CPU usage. When using the biquad filters for instance the CPU usage is in the nanoseconds. Perhaps on older CPU's it's a few 100 hundreds of ns. Well, unless you have hundreds or thousands of filters. Of course convolution (is this FIR?) or graphic eq as Equalizer APO calls it, is much slower. When using the Configuration Editor as Equalizer APO interface this is the standard way of EQ-ing. It's nice and fast enough but way slower than biquads filters. And perhaps that's the issue of your immense high CPU usage although it can't be measure per audio channel as you're mentioning. Of course it can be measured per core. And of course the audio delay can measured per channel.
Btw. What Equalizer APO does is getting the audio stream (after rerouting by its Configurator) and performing on it according the actions as stated in config.txt. As such the delay is in principle an amount of audio samples.
There is nothing stopping an APO from creating its own internal threads and then distributing work over them. EAPO doesn't do that, though.
Convolution/FIR and "graphic eq" aren't the same thing.
Convolution filters can be quite expensive if the filter is long (many taps). For example, DRC-FIR generates huge 65k-tap filters by default - if one were to filter all 8 channels of a 7.1 setup with 65k taps per channel, the CPU usage can definitely become a problem.
Thanks for the thorough response, Etienne.
I'm under the impression that the GraphicEQ command of Equalizer APO uses convolution by creating an internal impulse response "file". But I'm a noob on these things. Anyway, the source code suggests that convolution is used. For instance. the process methods of GraphicEQ and convolution are identical.
That begs the question of why using such elaborate filters. A bit overkill?
Sure. I was just clarifying that one can use convolution without using GraphicEQ, by supplying their own filters (impulse responses).
Long filters are necessary for high accuracy in the bass region. Clever calibration packages will combine IIR filters in low frequencies (for computational efficiency) with FIR filters in high frequencies (for higher precision and flexible phase response) to give the best of both worlds, but these combined filters are more complicated to design.
Thanks again. I think the command name 'GraphicEQ' isn't the best naming giving. Probably used because how it's presented in the Configuration Editor. I rather would call the command 'ConvolutionEQ' or something.
So when combining all kinds of filters explains the heavy CPU usage. If one wants precision the necessity for a fast computer arises.
I see these enabled (in .vcxproj)
<optimization>MaxSpeed</optimization>
<intrinsicfunctions>true</intrinsicfunctions>
<multiprocessorcompilation>true</multiprocessorcompilation>
Dunno what these actually results to in MSVC world (been using only GCC and Clang last few years (in Ubuntu)). With VC++ own tools one could check this.
"Directory change notification" runs in its own thread (FilterEngine class, IIRC).