Anyone know of a fix for the random pops when audio is playing or being adjusted rapidly? It happens occasionally depending on what song is playing, but is very random and unpredictable, not sure what is causing the random pops. They are quiet pops that aren't really that noticeable but still fairly annoying (much more noticeable on headphones).
I'm using eqAPO with Voicemeeter Potato (apo installed on A1,A2). Voicemeeter is going to my UMC204HD @ 96khz @ 256sample (ASIO). Ive tried changing the buffer size on WDM,MME, ASIO, etc but still no luck fixing it.
It seems to be something to do with eqAPO and not voicemeeter because I only recently installed it on A2 (my headphones, same ASIO interface). And its started happening to my speakers (A1), and my headphones (A2) now.
Any ideas what could fix it?
Thanks
Gershy13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes it is only graphic eq. is there any way to fix it rather than switch filter? i use AutoEQ for headphones, and they generate a graphic eq file that i load in.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess by taking the parametric EQ (peak filters).
Btw. peak filters is what the Peace equalizer uses for its EQ sliders, just to avoid the GraphicEQ issues (although it's possible to switch between by 1 single click).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately the last couple of years the developer isn't very active so don't expect a fix. For years in a row I'm doing the most support on Equalizer APO. Even I don't know what's wrong with GraphicEQ (convolution). I have some vague ideas but nothing concrete.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Say if i exported the graphic EQ into a wav file using VIBE, and then imported into eqAPO as convolution, would i still have the same issues as it is using convolution?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good thinking :) It might work so it's worthwhile trying it.
Internally the same processing is used but the creation of the convolution file of a GraphicEQ command differs. In that sense using the Convolution command is an easier internal process for Equalizer APO so perhaps it comes without the pops.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Based on my limited testing for about an hour, I haven't been able to come across any pops using both the graphic EQ or convolution wav file.
This could be due to multiple tweaks I did, however time will tell.
The first thing i did is moved my much simpler eq (only eq'ing 2-3 frequencies) for my main speakers from graphic EQ to parametric EQ, maybe this puts less stress on the system?
The second thing i did, which i suspect has the most impact, is apply the eq(s) to only two channels using the channel selection filter in configuration editor. This took the cpu usage estimate down from 1.7% one core to 0.5% and init time from 13ms to 4.9ms.
I assume this makes the eq significantly less cpu intensive. The weird part is my system is all stereo, yet for some reason the voicemeeter and eqAPO combo seems to assume everything in 7.1 (even though outputs and inputs are stereo).
Pops and crackles are now significantly less if any. I have noticed only one when using graphic eq, but not sure if that was a system hiccup or eqAPO. So far none when using convolve filter.
So for everyone having this issue, i recommend first setting channel output selection (its a "control" filter in configuration editor) to stereo unless you need all 8 channels.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Parametric EQ is based on peak filters. In all the 8 years I'm supporting Equalizer APO and developing/supporting the popular Peace interface, these kind of filters don't have any issues.
Using the channel command is alright but this only has an impact when using Graphic EQ. The biquad filters like peak filters are just too fast to have issues. But when using the virtual devices A1 to A5 of VoiceMeeter and applying some equalization on either of them may come with their own set of issues, mainly cracks and pops. And perhaps the weird 7.1 channel issue you're talking about.
One know issue is that the VoiceMeeterClient.exe being started too early on a computer startup.
Btw, Thanks for testing and sharing your experience and thoughts. They are important for improving the support on the proper usage of Equalizer APO.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, I didn't realise the EQs had different performance until now. So as i have two audio chains (speakers A1 and headphones A2), i decided to make both as optimised/performant as possible. Switching the A1 speakers to parametric was easy as its a very simple (two frequencies) EQ. Maybe that offloaded some of the work of the CPU.
Looks like if you want graphic EQ to work without too many issues with voicemeeter, try and keep CPU usage of eqAPO as low as possible. It seems that eqAPO was trying to eq all 8 channels before, so cpu usage is significantly lower doing only 2 now (especially with graphic EQ)
For headphones A2 ideally i'd like to keep using convolution (wav or graphic EQ) as its more accurate than parametric, and as i haven't had many problems recently, i'll stick to it. But if it does cause issues in the future i will switch to parametric.
I'll also try delaying the start of voicemeeterclient just to see if that helps with anything, as its not going to do any harm being delayed ever so slightly.
I also do have a pretty powerful PC so maybe that's why the graphic eq doesn't perform too bad in stereo only. (3800x 8c/16t)
I wonder if a faster cpu (single core) such as the 5800x would have less audio glitches.
I love testing things and messing around with my pc and especially audio, so im always happy to test and report back my findings so other people can benefit too!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for this info. I can now offer more solutions to this issue.
About the CPU, someone here on the forum reported that his multithreaded CPU was the problem or the problem on his computer. After switching off multihreading in the BIOS the cracks disappeared. This seems to suggest that somehow the processing of convolution is done on multiple threads. But this isn't what the programming code is saying, I believe (I'm not a C++ expert).
To summarize there are now 3 solutions for GraphicEQ related cracks and pops:
1. Delaying the VoiceMeeterClient.exe running at computer startup.
2. Reducing the number of channels to stereo (if possible) through a channel command.
3. Switching off multithreading in the BIOS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's very interesting... Maybe it has something to do with the audio engine using the threaded virtual cores instead of the logical cores? Maybe the virtual threads do not perform as well as the logical cores, so when it is enabled eqAPO uses essentially less powerful cores? If there was a way to force it to use a specific core(s) that could be an interesting test.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps it is. I don't really know how things are programmed or compiled. Changing the usage of cores would indeed be an interesting test.
As the biquad filters (peak, etc.) are ultra fast, it's a rather simple calculation, convolution is more CPU consuming. But still it's quite fast so there shouldn't really be pops and cracks on our fast computers of today. So the only thing I can come up with is that a task gets somehow divided on multiple threads, not on purpose but by "accident". If these are virtual threads then any consuming computer process may get convolution into trouble as the priority might be set low. But have said this, I'm really not an expert so I could be terribly wrong with this assumption.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So after some more listening, it seems like the pops are still there, although the amount of them seems to have decreased. To be honest i'm not sure how to fix it. I tried using parametric only (disabling all graphic eq and convolution), and i still seem to get them. So this leads me to think maybe it is not eqAPO and something else in my sound chain. Maybe it is a voicemeeter fault?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it must be VoiceMeeter or the "connection" between Equalizer APO and VoiceMeeter. I did have much distortion when using the virtual devices A1 to A5. Fortunately I'm not depending on VoiceMeeter like a YouTuber may be so I simply stop using VoiceMeeter. I tried using the same sample frequency for the speaker audio device. So that the sample frequency on the audio panel of the speaker device the same as the one in VoiceMeeter. But it didn't seem to do the job. Next I increased the sample buffer in VoiceMeeter. This did decrease the distortion but introduce, of course, a larger sound delay. Again delaying VoiceMeeterClient.exe startup seemed to work for most.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anyone know of a fix for the random pops when audio is playing or being adjusted rapidly? It happens occasionally depending on what song is playing, but is very random and unpredictable, not sure what is causing the random pops. They are quiet pops that aren't really that noticeable but still fairly annoying (much more noticeable on headphones).
I'm using eqAPO with Voicemeeter Potato (apo installed on A1,A2). Voicemeeter is going to my UMC204HD @ 96khz @ 256sample (ASIO). Ive tried changing the buffer size on WDM,MME, ASIO, etc but still no luck fixing it.
It seems to be something to do with eqAPO and not voicemeeter because I only recently installed it on A2 (my headphones, same ASIO interface). And its started happening to my speakers (A1), and my headphones (A2) now.
Any ideas what could fix it?
Thanks
Gershy13
What Equalizer APO commands are you using? If GraphicEQ then try to use peak filters instead. GraphicEQ may have some issues sometimes.
yes it is only graphic eq. is there any way to fix it rather than switch filter? i use AutoEQ for headphones, and they generate a graphic eq file that i load in.
I guess by taking the parametric EQ (peak filters).
Btw. peak filters is what the Peace equalizer uses for its EQ sliders, just to avoid the GraphicEQ issues (although it's possible to switch between by 1 single click).
Alright I'll give parametric a shot. Is there any reason why graphic EQ is buggy? Are there any planned fixes?
Unfortunately the last couple of years the developer isn't very active so don't expect a fix. For years in a row I'm doing the most support on Equalizer APO. Even I don't know what's wrong with GraphicEQ (convolution). I have some vague ideas but nothing concrete.
Say if i exported the graphic EQ into a wav file using VIBE, and then imported into eqAPO as convolution, would i still have the same issues as it is using convolution?
Good thinking :) It might work so it's worthwhile trying it.
Internally the same processing is used but the creation of the convolution file of a GraphicEQ command differs. In that sense using the Convolution command is an easier internal process for Equalizer APO so perhaps it comes without the pops.
I've used VIBE to generate a wav file at 96khz (my sample rate) so i'll give it a shot and post back with my results in a few days!
Great! Love to know your findings.
Based on my limited testing for about an hour, I haven't been able to come across any pops using both the graphic EQ or convolution wav file.
This could be due to multiple tweaks I did, however time will tell.
The first thing i did is moved my much simpler eq (only eq'ing 2-3 frequencies) for my main speakers from graphic EQ to parametric EQ, maybe this puts less stress on the system?
The second thing i did, which i suspect has the most impact, is apply the eq(s) to only two channels using the channel selection filter in configuration editor. This took the cpu usage estimate down from 1.7% one core to 0.5% and init time from 13ms to 4.9ms.
I assume this makes the eq significantly less cpu intensive. The weird part is my system is all stereo, yet for some reason the voicemeeter and eqAPO combo seems to assume everything in 7.1 (even though outputs and inputs are stereo).
Pops and crackles are now significantly less if any. I have noticed only one when using graphic eq, but not sure if that was a system hiccup or eqAPO. So far none when using convolve filter.
So for everyone having this issue, i recommend first setting channel output selection (its a "control" filter in configuration editor) to stereo unless you need all 8 channels.
Parametric EQ is based on peak filters. In all the 8 years I'm supporting Equalizer APO and developing/supporting the popular Peace interface, these kind of filters don't have any issues.
Using the channel command is alright but this only has an impact when using Graphic EQ. The biquad filters like peak filters are just too fast to have issues. But when using the virtual devices A1 to A5 of VoiceMeeter and applying some equalization on either of them may come with their own set of issues, mainly cracks and pops. And perhaps the weird 7.1 channel issue you're talking about.
One know issue is that the VoiceMeeterClient.exe being started too early on a computer startup.
Btw, Thanks for testing and sharing your experience and thoughts. They are important for improving the support on the proper usage of Equalizer APO.
Yeah, I didn't realise the EQs had different performance until now. So as i have two audio chains (speakers A1 and headphones A2), i decided to make both as optimised/performant as possible. Switching the A1 speakers to parametric was easy as its a very simple (two frequencies) EQ. Maybe that offloaded some of the work of the CPU.
Looks like if you want graphic EQ to work without too many issues with voicemeeter, try and keep CPU usage of eqAPO as low as possible. It seems that eqAPO was trying to eq all 8 channels before, so cpu usage is significantly lower doing only 2 now (especially with graphic EQ)
For headphones A2 ideally i'd like to keep using convolution (wav or graphic EQ) as its more accurate than parametric, and as i haven't had many problems recently, i'll stick to it. But if it does cause issues in the future i will switch to parametric.
I'll also try delaying the start of voicemeeterclient just to see if that helps with anything, as its not going to do any harm being delayed ever so slightly.
I also do have a pretty powerful PC so maybe that's why the graphic eq doesn't perform too bad in stereo only. (3800x 8c/16t)
I wonder if a faster cpu (single core) such as the 5800x would have less audio glitches.
I love testing things and messing around with my pc and especially audio, so im always happy to test and report back my findings so other people can benefit too!
Thanks for this info. I can now offer more solutions to this issue.
About the CPU, someone here on the forum reported that his multithreaded CPU was the problem or the problem on his computer. After switching off multihreading in the BIOS the cracks disappeared. This seems to suggest that somehow the processing of convolution is done on multiple threads. But this isn't what the programming code is saying, I believe (I'm not a C++ expert).
To summarize there are now 3 solutions for GraphicEQ related cracks and pops:
1. Delaying the VoiceMeeterClient.exe running at computer startup.
2. Reducing the number of channels to stereo (if possible) through a channel command.
3. Switching off multithreading in the BIOS.
That's very interesting... Maybe it has something to do with the audio engine using the threaded virtual cores instead of the logical cores? Maybe the virtual threads do not perform as well as the logical cores, so when it is enabled eqAPO uses essentially less powerful cores? If there was a way to force it to use a specific core(s) that could be an interesting test.
Perhaps it is. I don't really know how things are programmed or compiled. Changing the usage of cores would indeed be an interesting test.
As the biquad filters (peak, etc.) are ultra fast, it's a rather simple calculation, convolution is more CPU consuming. But still it's quite fast so there shouldn't really be pops and cracks on our fast computers of today. So the only thing I can come up with is that a task gets somehow divided on multiple threads, not on purpose but by "accident". If these are virtual threads then any consuming computer process may get convolution into trouble as the priority might be set low. But have said this, I'm really not an expert so I could be terribly wrong with this assumption.
So after some more listening, it seems like the pops are still there, although the amount of them seems to have decreased. To be honest i'm not sure how to fix it. I tried using parametric only (disabling all graphic eq and convolution), and i still seem to get them. So this leads me to think maybe it is not eqAPO and something else in my sound chain. Maybe it is a voicemeeter fault?
Yes, it must be VoiceMeeter or the "connection" between Equalizer APO and VoiceMeeter. I did have much distortion when using the virtual devices A1 to A5. Fortunately I'm not depending on VoiceMeeter like a YouTuber may be so I simply stop using VoiceMeeter. I tried using the same sample frequency for the speaker audio device. So that the sample frequency on the audio panel of the speaker device the same as the one in VoiceMeeter. But it didn't seem to do the job. Next I increased the sample buffer in VoiceMeeter. This did decrease the distortion but introduce, of course, a larger sound delay. Again delaying VoiceMeeterClient.exe startup seemed to work for most.