Hi everybody.
I love the convolution reverb. It sound very natural and since I’ve hear it with my guitar I can’t use something else.
I bought two plugin from DoGood sound. The plate reverb and the silo reverb.
Both sound fabulous but the silo make big cpu jump with my Mod Duo X. I have no issue with the plate reverb on my Mod Duo X.
I tought it cames from my Mod duo X that load big pedalboard so I bought it for my Mod Dwarf and I have the same issue.
With a very simple pedalboard that use LP3 looper, a reverb and a freeze plugin there are lots of CPU jump. This make this plugin unusable on both unit.
CPU usage is around 56% on my Mod duo X and 40% on my Dwarf.
I have tha same issu with the free convolution reverb that includes various IR.
Is there someone here that don’t have issue with these convolution reverb?
I have this same with DoGood Korea on Dwarf - lots of jumping CPU. The board is not complicated and from about 60% of CPU jumps to 99% al the time.
Why are there so few messages from users when there are issues?
And why Mod team don’t care?
Did they test this plugin in real situation? If they did they should see there’s a problem.
This is a huge leap forward in reverb effects for Mod units, I point out that there is a big CPU usage problem that makes these reverbs unusable and I have no answer. I’ve been complaining about this for several weeks and I thought no one else had this problem.
I spent 40€ for an unusable reverb, but I’m cool, I’m not going to make a scandal on the internet or facebook, others will certainly be less cool than me.
Now I know I’m not alone.
Thanks @Lukasz
Have you tried different combinations of effects to see if there are still CPU jumps?
I bought Dwarf two weeks or so ago, so I’ve made only few boards using this same plugins like red apple, vintage cab, EQ plus DoGood - nothing complicated. When I add rakarrack (harmonic something) my dwarf reaches 99%, so it strats to glitch. I use Dogood reverbs on my DUOX but I can not remember if there has been this same issue -I must make some tests. The problem is that the jump of CPU is higher than 30% so it is really easy to reach Dwarfs max CPU = cracks and glitches.
Can you share a pedalboard where this happens?
For IRs such as “Grain Silo” it is going to take quite some CPU, it is a very long IR (around 15s or so).
Because of background processing, the average displayed CPU load is not fully representative of the CPU consumed by the plugin. It is a similar situation with x42 IR loader too.
The MOD convolver and DoGood ones always use 2 extra threads for background processing, one per audio channel. If there are 2 or more parallel audio chains on the pedalboard (one of them with the convolver), they can end up competing for resources
Ok. I’ll share my Dwarf Pedaboard. It’s a very simple pedalboard but indeed there are several parallel effects of the LP3 looper.
I understand now that IR convolver are very CPU hungry. But why when I put the reverb everything is fine then after a few minutes the CPU usage increases from 50% to 100% on the Mod Duo X. I did not think that these IR convolvers could take more than 50% of the power of the Mod Duo X which is the most powerful of your Mod devices! That’s crazy.
That is a weird one indeed. I tried to reproduce the issue locally but was unable to.
There might be other things at play here, are you using net+midi usb option? WiFi? Is your unit the newer one with a power button near the power jack, or the limited edition one?
My Mod Duo X as the power button. I’ll share my Duo X pedalboard too. There’s no parallel processing on this pedalboard and CPU usage is about 45 to 50% before I load the Silo convolver reverb. And don’t use midi on this unit.
Same problem here involving the MOD Convolution Reverb,when I activate the CHOWDSP it jumps from 65% to 100% …Here is the pedalboard:
Can reproduce this with some tweaking on the PB, thanks!
One thing that I see is that pushing the average CPU load above 70% makes it jump a bit, but if it is always below 70% I dont see any jumps.
are you using the chow in neural mode? This eats up much more than standard.
It happens in both modes.
this is not so much related to cpu usage, but jump in them.
cpu load jumping from 75% to 96% is certainly not normal on a full realtime system. the load is meant to be consistent, assuming the PB is also not changing too (bypassing some plugins can reduce load if they implement a custom bypass, like it is the case of chow centaur).
this is definitely a bug that needs to be dug into and resolved.
Don’t know if it helps, here is another exemple:
Same Pedalboard with the MOD Vintage Cab, same problem in High fidelity mode, no problem in Normal fidelity mode, less CPU of course but no jumps, stays under 60%.
Can you recommend a reliable way to time the execution time of the run() function. I do this on my hardware loopers to collect min/avg/max execution time for this critical function.
Also, I suspect that there is something going on with either the file system or the storage medium driver. Operations that save/load files seem to impact the audio and cause the xrun count to go up and glitch the audio. For example, save/load on the LP3 or saving the pedal board.
for testing you can pin the current audio thread to 1 specific cpu core and use cpu cycles as timer metric.
that gets you the highest possible timing results.
otherwise just normal operations to get current time should work too.
there are no NTP events that would shift the clock around, so CLOCK_REALTIME is safe to use.
Just a guess, but, as far I know mod-host is a single plugin host, the real work on connection and process is done by jackd. So, that means there is NO single worker thread shared by all plugs to do heavy work in the background. So, every plug open it’s own worker thread which then competing for resources.
Hence, for file save operations it may be a good idea to use a streaming approve, means, split the vector into parts, and call the worker thread for short operation time, that will reduce the competing, and help to reduce context switching.
Actually, the LP3 does all file operations in a different thread to hopefully avoid impacting the audio thread. The audio thread runs at real-time priority. The file operations are done at a normal process priority.
I’ll give this a try to see if I can see any issues in the LP3 run() function.
Sure, and so do all plugs with background processing. As more processes run, as more likely is that even in the audio thread, which runs with rt-prio, a context switch happen. That leads to CPU jumps and X-runs. That happen when several processes ask for free CPU time. Even the audio thread may switch then over to a other CPU to give the CPU time free on the CPU it used before. In that case it needs to take all the data with it, voila, context switch. rt-prio didn’t prevent us for that case, even threads with the lowest possible priority could lead to such a switch.
I’ve once written a app to follow that cases and checked how I could avoid that. The point is, that working with small chunks of data and then send the tread to sleep for some micro sec, helps a lot. As it gives the scheduler alternatives on which CPU to put a workload requested by a other thread, and there is no data left which needs to copied over to a other CPU cache. That helps to keep the audio thread away from context switching.