Intermittent Pops / Crackles but CPU only at 75%?

sprint

Axe-Master
I have a large preset (stereo path thru 2 drives / 2 amps / stereo cab + numerous fx blocks) which is exhibiting CPU max out characteristics (intermittent pops / crackles) but my cpu is only at 75%. I've removed the following culprits from the equation but it still persists (removed usb connectivity, removed midi connectivity, removed spdif connectivity, listening directly thru headphones).

I can reduce the pops by simplifying the patch but I can't tell which blocks are stressing the cpu (reducing drive/amp/cab complexity does not necessarily solve it). Edit: I have to remove enough FX blocks to reduce CPU by about 10% in order to eliminate the pops.

I know there are 2 cpus in the Axe3 - is it possible I'm overdriving one of the 2? How can I tell?
 
Last edited:
Here it is.

I will acknowledge in advance of the inevitable comments that, this kitchen sink patch has probably gotten too complicated but it works perfectly for me other than the digital "pops" that are occurring, so I'd like to keep everything in it if I can. An obvious solution is to simplify it - so again - I'll acknowledge that in advance. (for those who are curious, this is a kitchen sink preset which also lets me bring outboard fx on loops 2,3,4 in/out as desired (ie swap Axefx delay w Nemesis Delay in loop2 / swap Axefx Harmonizer w outboard Axe2 harmonizer in loop4 / swap Axefx drives with outboard drives in loop3 / swap in a plugin / add in some freqout pedal in loop3 - I've got the switching for this to be seamless with some custom footswitch programming - note that all the loops can be removed for simplification but the "pops" remain)

What I'm curious about, is how I'm apparently hitting cpu limitations with a 76% cpu reading. My own hypothesis is that I'm maxing one of the 2 cpus with too many fx blocks - if the consensus is that that's the reason then I'll adjust accordingly but I'd like to hear any other insight if available as this will help with patch construction (ie - is a list somewhere of what blocks are using which cpu or is it dynamic somehow).
 

Attachments

  • POPs76%.syx
    48.2 KB · Views: 2
i'm not at my axe, but do you have any controllers assigned? especially to the Drive in the Amp block? controllers use cpu when active, and i believe Drive takes a lot of real-time processing.
 
Yes - tons - 25 Controllers (and as noted above I'm using 2 Drives / 2 Amps and Stereo cab blocks)

I'm not in much doubt that I'm hitting one or the other cpu too hard - but given that I can get the unit "popping" at 65-70% on the visible CPU readout, I'm wondering if there's any way to "procedurally" balance the load more effectively somehow.
 
Last edited:
Yes - tons - 25 Controllers (and as noted above I'm using 2 Drives / 2 Amps and Stereo cab blocks)

I'm not in much doubt that I'm hitting one or the other cpu too hard - but given that I can get the unit "popping" at 65-70% on the visible CPU readout, I'm wondering if there's any way to "procedurally" balance the load more effectively somehow.
it's the controllers then. they probably enable too briefly to see the CPU readout spike up.
 
it's the controllers then. they probably enable too briefly to see the CPU readout spike up.
Nope - I just removed all controllers but 1 and still get popping although there less of it (exercising the one remaining controller (wah) brings it out more - sometime I have to play a while to get a few pops). To me it looks like we can max one cpu while the other still has capacity and the overall CPU level shows lots of room remaining. Interestingly - removing one of the two amp blocks and one of the two drive block (set up to run in stereo - with same settings on each) solves it (which suggest's I'm maxing the cpu that's dedicated to distortion). I dunno - kinda looks to me like the unit tries to balance across the 2 cpus but if you've got a lot in one patch it may or may not balance in your favour and you can end up with digital clipping from lack of cpu even the the unit overall has enough cpu - it's impossible to know really - but if there are some balancing considerations to patch construction, it would be nice to know what those are.
 
pretty sure 1 cpu is the Amp and system, other is all other blocks except cab which has its own "accelerator" or something like that (i'm not an engineer).

not sure what's going on, but i'm sure some will check out your preset soon.
 
That makes sense, since just removing one of the 2 amp blocks solves the popping.

Interestingly, replacing 1 of the 2 amp blocks with a shunt does NOT impact the overall CPU readout at all - even replacing both amp blocks with shunts leaves the overall CPU readout the same which leads me to believe the overall CPU readout does not include the status of the "amp side" cpu.
 
Don't know if it will help you or not, but here's one of my "kitchen sink" patches which is just above 84% with two amp paths, and I'm getting no pops.
 

Attachments

  • Boogomica.syx
    48.2 KB · Views: 4
That makes sense, since just removing one of the 2 amp blocks solves the popping.

Interestingly, replacing 1 of the 2 amp blocks with a shunt does NOT impact the overall CPU readout at all - even replacing both amp blocks with shunts leaves the overall CPU readout the same which leads me to believe the overall CPU readout does not include the status of the "amp side" cpu.
Correct because that’s mostly all that cpu does.
 
Don't know if it will help you or not, but here's one of my "kitchen sink" patches which is just above 84% with two amp paths, and I'm getting no pops.
Thanks - that does help since your patch does not pop for me either so gives me a basis of comparison to figure out why mine is causing issues.
 
Correct because that’s mostly all that cpu does.
ya - would be nice to have an "amp side cpu" metric somewhere - only having the one can be quite deceiving (your axe is telling you 70%, but your dimed on the amp side cpu).
 
ya - would be nice to have an "amp side cpu" metric somewhere - only having the one can be quite deceiving (your axe is telling you 70%, but your dimed on the amp side cpu).
But that cpu shouldn’t matter because it only handles what it can handle. Unless you’ve found an exception, it’s never been an issue. That’s why it’s “hidden.”
 
But that cpu shouldn’t matter because it only handles what it can handle. Unless you’ve found an exception, it’s never been an issue. That’s why it’s “hidden.”
Not sure I underatand your logic - it matters in that if a preset is using 98% of the amp-side cpu and the overall CPU status (based on the non amp side cpu) indicates 70%, then the user would be led to proceed thinking there's lots of cpu breathing room (based on the one status available), when in fact, the patch is on the edge of clipping due to the hidden status of amp side cpu. Maybe you mean that the amp side cpu should never be able to get maxed out - but this patch seems to indicate otherwise at this point of the analysis.
 
Maybe you mean that the amp side cpu should never be able to get maxed out - but this patch seems to indicate otherwise at this point of the analysis.
yes that's what i meant by "unless you've found an exception." historically, the Amp CPU should never overload. i'll try your preset in a few minutes, just got home.
 
i think it comes down to the controllers. there's so much going on here and all those changes take CPU to calculate and change

Screen Shot 2019-11-21 at 7.59.38 PM.png

that is A LOT changing with a pedal or whatever you're using. pretty sure there's just too many controllers.

as i mentioned earlier, even just the Amp block Drive changing is a lot of CPU in real time.
 
thanks for investigating - I'll look into the controllers as I agree that those are a likely culprit. I know there's a lot, but I'm not sure about "too many" as the unit allows for 7 more than I have. If the controllers are maxing amp/system side cpu, then the overall cpu readout is very misleading in patches like this (user won't know that cpu is critical until they start hearing pops).
 
Last edited:
Back
Top Bottom