I would like to report that I am experiencing a dramatic drop in computational performance, in V5 with latest Oram, when loading a snapshot previously created in Stable (July 2024) on the same Zynthian device.
While the 16-channel snapshot was easily handled by the same hardware with the previous OS, once loaded in Oram it produced straight away the red warning blinking symbol on the top right angle of the screen, alternated with the green heart.
If the related project is played and sent to Zynthian, the result is immediately a tsunami of x runs and audio dropouts, to the point that the audio system becomes clogged and completely silent in a few seconds.
Any ideas about what is happening? (there are other issues related to snapshot import and compatibility, which I will report in another post - pulled an issue ticket on GitHub).
My suggestion for a potential culprit is the way some existing effects processors are reassigned in Oram as (maybe) post-fader FX, with ensuing overload of the CPU and audio system. Just an idea… I seem to feel that it could be an effects-related problem.
When I have time, I will try to rebuild from scratch the same snapshot directly on Oram, to see what happens! (on my bare-bones Pi5/nvme Oram it works without a glitch, apart from wrong audio levels overall, edit: so I don’t think it depends on old 32 bits plugins in a new 64 bit environment).
I seem to have been able to discover what caused a drastic and unexpected decrease in CPU performance, on my V5/Pi4 official kit, switching from Stable (July 2024) to Oram (fully updated to Latest).
Patiently analysing, chain by chain and fx processor by fx processor, a 16-channel snapshot that worked brilliantly before updating, I discovered that SURGE XT and HELM produce almost instantly the red triangle warning, whatever preset loaded, and lots of x-runs/audio dropouts.
I tried to pinpoint the issue creating very simple trial snapshots, with no more than three midi chains: if one of the channels is Surge XT or Helm, this causes straight detectable x-runs and the red blinking warning, also with very few Midi notes played.
I suggest that it might depend on the related LV2 synthesiser plugins’ hosting/integration/low-level data exchange, within Raspberry OS 64 and/or Oram.
Could the problem be Pi4 specific? It does not happen on my Pi5 Oram with the same OS revision.
I just tested with both engines in my V4 Pi4 device. I crated 2 chains, one with Surge-XT and another one with Helm. Then created some patterns and start playing.
with VNC disabled => No issues at all. CPU usage remains quite reasonable. Helm consuming almost nothing and Surge-XT a little bit more, as it always did. It’s a heavy engine.
With VNC enabled => CPU is higher, but still no XRUNs. It’s Helm GUI what is causing the CPU increase. Disabling “animated graphics” from Helm’s GUI reduced CPU consume a lot.
My conclusion:
Helm’s native GUI always has been very CPU eager. It has been disabled in zynthian for a long time, but i decided to re-enable because i discovered that disabling animated graphics mitigates the problem. I will try to find a way of disabling this by default. Any help on this will be apreciated
Surge-XT (and old Surge) always has been very heavy. Many presets can’t be used in the Pi4 without producing XRUNs. It must be used it with care in Pi4. Having the native GUI enabled (VNC) doesn’t help, of course.
I have to say that I am quite perplexed at this point, because I have no VNC enabled in my V5 (I am aware of its relevant computational overhead), and my Oram just comes from the latest updates of a freshly burned SD, a few days ago.
If I add a chain of Surge XT to an otherwise solid snapshot of - say - three Zynaddsub, Sfizz and Tal-NoizeMkr channels (that is, Zynthian ordinary business stuff) my V5 goes immediately in red-triangle warning mode, and Midi data sent to the “culprit thug” causes x-runs straight away. The same, to a lesser but very detectable extent, goes on with Helm.
The exact same behaviour is shown if I just add a single Surge XT chain to a new empty snapshot.
I am starting to suspect that something has gone wild, with my Oram installation and ensuing updates. I will try to reset the system with a freshly flashed SD from the Oram repository, and see if the problem disappears or persists.
By the way and FYI, the same snapshots (up to 16-channel with effects) within an equally updated Oram do not break a sweat on my Pi5 Zynthian, not a glitch. But this is certainly due to higher CPU muscle.
I have not managed to make my V5 xrun with just Surge XT in a single chain. Surge’s resource usage is heavily dependent on the features the patch / preset uses. Can you give an example of a preset that triggers this issue? Do you have any effects, e.g. in the main chain? Are you sure VNC is disabled?
Thanks for delving into the subject. I am pretty sure that I have not the VNC server enabled. The red triangle warning sign appears, with ensuing x-runs while playing, with whatever preset I select. For the sake of experimental method, let us say the first patch of the arps…
I can’t reproduce this issue but i would like to understand what is going on in your side.
Could you make a video of the terminal running “htop” while generating the XRUNs?
I have flashed again a pristine June 2024 Oram OS on SD, and tried to build a super-simple snapshot with only a Surge XT chain/channel (no VNC of course). I obviously resisted any alluring calls for green whirlwind updates!
The result, as clearly shown in the video clip (sorry for tilted orientation) is immediate red triangle warning sign and strong x runs, which leads within a few seconds to the audio system being totally clogged and silent (terminal with htop command video also attached).
Needless to say that the test snapshot for my project with 16 channels gives straight away CPU overload warning and is totally non-playable.
I dare not say that it might possibly be something with my V5 hardware (the Pi4 board, some bus component?).
Edit: another issue scenario that pops in my mind could be, albeit rather unlikely, that CPU overclocking is not really active although webconf signals otherwise.
Thanks, will check! (yes, watching the video it might seem that some CPU thermal throttling is happening, going from the red lines in the monitor of the four cores).
You should check that thermal block is well installed. It 's easy to check by monitoring the temperature from webconf. Use F5 to reload the dashboard and get updated temperature. It shouldn’t go over 40-50 °C. Also, you should note the aluminum case warming, especially if temperature is over 40.
If temperature going too high (over 60) and the case is not getting hot, something is not well installed in your passive cooling.
1] I have tightened the two screws on the back, that hold the thermal block tight to the case.
2] I have run vcgencmd measure_temp in terminal under stress (both with only one Surge channel and a larger snapshot with Surge): operational temp does not exceed 42.5 degrees.
3] I have also run vcgencmd measure_clock arm in terminal, to verify current CPU clock: it returns as expected 2 billions cycles/sec, that is full overclocking to 2 GHz.
Red warning sign continues and dramatic x-runs follow, that soon lead to silent audio system, with whatever number of loaded chains from 1 to 16. The underside of the V5 around the screws becomes increasingly warmer, as expected.
