This is a proposal to hopefully avoid xruns. I don’t experience them often, but once in a while is already too much.
The idea is to downgrade the rendering sampling frequency before hopefully overloading occurs. For instance, if the CPU load goes above 80%, then for the subsequent audio buffer, it would divide the sampling frequency by half, going from 48KHz to 24KHz, and put it back up to 48KHz as soon as the load goes back under 40%. The jack frequency wouldn’t change but the host would make the engines/plugins believe that the host frequency has switched to 24KHz, then the host would stretch and interpolate with an inexpensive LPF or such. Of course for that to work it assumes the engine/plugin can switch it’s rendering frequencies without producing glitches, this is the hardest part I think, but since all these are free softwares, this is probably addressable by the community.
Of course one would still want to avoid rendering at lower frequencies, but this would be used as last resort when all parameter configurations to avoid xruns have failed.
Hi @ngeiswei!
Thanks a lot for your proposal. The problem of overloading the CPU is quite annoying, specially with some ZynAddSubFX presets.
Your proposal’s concept is nice, but i think it’s very difficult to implement. Really! Normally, plugins/synth engines doesn’t support changing the sampling rate on the fly. It have internal buffers, pre-calculated tables, and other esoteric structures that should be re-calculated (or stored for every sampling rate). Also, audio data flow is managed completely by the jack daemon. The plugin “host” don’t touch the audio data and of course, jack daemon doesn’t support changing the sampling rate on the fly, as it would force the clients to support it. And if it doesn’t support this interesting feature is because it’s really complex to implement.
Of course, you or anybody is very welcome to try it. The person who get this scheme working will have my eternal admiration 
Super Regards!
Of course! No need to bother the host. Since the hardest part is having the plugin smoothly transition between 2 sampling rates anyway, we can have the overload detection code live within the plugin itself (possibly wrapping that code in a library for re-usability).
I think that makes the whole thing slightly easier, though still hard. I suppose one could try with a simpler engine/plugin at first, as proof of concept, then attempt to adapt that to more sophisticated synths like ZynAddSubFX. Yes it is a big under taking, and maybe by the time it is working the RPi4 will have eliminated the problem.
Maybe this powerful and pricey competitor of the RPi3 https://opensourceforu.com/2017/05/huawei-raspberry-pi-competitor-android-support/ is gonna motivate the Raspberry Pi Foundation to make the RPi4 that Zynthian needs 
The features are really good, but the target price is $240!! Bufff! 
Regards!
Sounds very interesting - but not for $240… for this money you can buy a Intel-NUC and don’t need to cross-compile all software. Without looking at the specs, I think a NUC has more RAM, more CPU and better interfaces for mass storage.
Regards, Holger
