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.
1 Like
Same problem here involving the MOD Convolution Reverb,when I activate the CHOWDSP it jumps from 65% to 100% …Here is the pedalboard:
2 Likes
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.
6 Likes
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.
1 Like
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.
1 Like
I think I have a lead.
I noticed that the number of x runs increases each time the pedalboard is changed and that is what causes the cpu usage peaks.
When I load the pedalboard with the Silo reverb for the fist time cpu usage is at 60% and X runs at 13.
Each time I load a new pedalboard cpu usage increase and X run too up to more than 200 for the same pedalboard! Of course the audio drops appear and I can’t activate any effect without cpu drop to 100%
@falkTX Is this normal?
5 Likes
for sure not normal. but a great starting point to investigate further, thanks.
4 Likes
the both photos above are for the same pedalboard !
The first photo is when I load the pedalboard just after having power up the Mod Duo X and the second after opening 6 or 7 differents pedalboards.
@falkTX
I’m playing with the silo reverb and many plugin since 30 minutes without any audio drops. But as soon I change IR in the silo effect XRUNS and CPU usage increase until audio drops appear.
I think it’s a issue that you can easily recreate at home.
BTW, I’ve added max elapsed time capture of the run() function and just adding that code has resulted in better CPU performance. I suspect that many of the XRUNS are connected to Linux scheduling.
7 Likes
@Julien please test the latest “Odd Ones” reverb that was just pushed to the store today, and see if the CPU-increase behaviour also happens when using only that one.
using it in demo mode is quite fine, it is not the sound output we are interested here.
thank you!
I have made small tweaks to its thread sync mechanism, that I suspect could be related. so worth a shot…
if confirmed I would push the change to the other reverbs.
6 Likes