i’ve seen some strange things like that, but am not sure if it relates to a specific plugin. on a lot of my pedalboards which run normally with a safe CPU load (50-75%), the load spikes to 100% periodically and an xrun occurs. …maybe once every 5 minutes or so.
it’s annoying and i think it’s a new “feature” in the current system version, or maybe this one and the last one.
i don’t mean to hijack your thread, but perhaps the two issues are related?
for me, this would be a tough thing to get good observations about, since it’s intermittent and happens with various combinations of plugins.
The DSP load is just a rough average. Is says nothing about standard deviation. So maybe this is an error from the “the map is not the terrain”-class.
Please provide a reference pedalboard (can you share it online and point a link to it?) and I will have a look at it.
@plutek thank you for sharing your pedalboard. I installed a Duo with version 188.8.131.524 and the board you shared is constantly producing XRUNs. If I remove the BETA-plug-in, the DSP load is below 75% and it did not produce XRUNS for 15 minutes.
Please note that BETA plug-ins are not guarantied to meet the quality standard of normal plug-ins.
@Tarrasque73 On the same fresh Duo the Super Whammy runs at below 55% when set to HiFi. The plug-in is known to have a high DSP usage. But your case seems to be unusual.
yes, this pedalboard produces xruns constantly at 128 frames. i’m curious if you tried it at 256 frames – at that setting, it shows the strange behaviour of being generally fine, but spiking to 100% load occasionally.
and, yes, i do understand that beta plugins aren’t guaranteed to be reliable! it just seems strange that a pedalboard produces those occasional 100% spikes, when it’s generally running in a more reasonable range.
perhaps i’ll build a test pedalboard with a similar DSP load at 256 frames, but with NO beta plugins, and see if it exhibits the same behaviour of strange intermittent load spikes.
so, after watching this issue for a while now, i’m coming to the conclusion that it’s really not about beta versus non-beta plugins. (although there is great variability in the xrun behaviour of various beta plugins – choose wisely because some are fine and some are not – lots of testing of any particular pedalboard before it sees the stage or studio is key!)
i’m now pretty convinced that the only way i can entirely avoid this problem is to keep the pedalboard load under 75% at 128 frames only. it seems that if a pedalboard is complex enough that i have to drop to 256 frames in order to keep the load under 75%, there will inevitably be some xruns if i just wait long enough.
unfortunately, it’s a difficult problem to test rigorously, with various combinations of plugins. a lot of what i’ve been building up 'til now has required 256 frames, so i’m going to be examining whether it will work for me to simplify things, and make more use of pedalboard banks to switch setups during a performance.
given the processing power that’s been demonstrated on the Duo X, i’ll also be eagerly watching for any news of CPU upgrade options for the Duo!
@plutek I have been doing some tests with the pedalboard you shared, it is supposed to be used with 256 frames right? Because with 128 the Duo simply cannot cope with it.
With the upcoming changes (for v1.10) there are no xruns with it after 5+ minutes.
If you have other pedalboards that are consistently problematic, would be very useful. I can use them as test-case before public release.
the second one (cart_of_flowers) has no input at all – it’s just a generator.
the first one normally has input, but triggers the xruns regardless of whether input is present or not.
also… i’m just now running a test with a new pedalboard (just the default with only a stereo gain plugin). it is showing 1 xrun after having been running for about 1hr30min. i didn’t actually see when it happened, so can’t say whether the cpu usage spiked or not. i’ll leave it running and keep reporting… is this sort of long run of a minimal board something you’ve tested?
…after 17 hours, i have a total of 7xruns.
next, i’ll try to capture both video and audio for a long time, to see if the cpu % is spiking, and if the dropouts are affecting the audio…
ok… i’ve observed the cpu spiking to 100% (accompanied by 3-4 xruns), just after an audio discontinuity, a number of times now. it’s happening every 1 to 2 hours on this minimal pedalboard – i added a tone generator so we could see what’s happening to audio but the xrun and cpu spike count is very similar to a default new pedalboard:
here’s a short video of one of the events: MOD_cpu_spike_movie
…you can see and hear the audio discontinuity at about 8 seconds into the video, followed by a cpu spike to 100% at about 8.5 seconds. this is typical of what happens periodically.
Note that the “CPU spike” is not real. We fake that when an xrun occurs, because JACK2 gives an average DSP load rather than the “worst-case” value (which is more useful).
The CPU is not randomly going to 100%, BUT we do have random xruns in that case yes.
The good news is that we do not see those sporadic xruns with the mainline kernel.
But I still need to finalize a few things here before public builds are available…
Oh and of course, thanks for your time on this. It is really useful
Alright, I fixed up the remaining issues there were with the codec driver, so now mainline kernel fully boots and is working as expected.
Opted to go with 5.4, since that is LTS.
Now we mostly have other things to handle, which are not related to the kernel.
Some internal testing first, thanks @plutek again
One question though… that “cart of flowers” pedalboard, it outputs noise right? it is what I get by default; the “note/noise balance” slider leads me to think it is correct.