Just guessing: should we narrow the problem down to CPU cores behaviour, couldn’t it be that there is inconsistent or insufficient power delivery to the CPU, in order for it to sustain the set overclock?
This would probably result in unpredictable performance under computational stress. However, I would hardly say that a single chain with a synth engine may amount to computational stress.
What do you think?..
Temperature update after one hour on, with a 16-channel snapshot loaded but no midi note sent nor midi playing:
CPU temp stabilised at 43.5 degrees (room temp about 30)
Underside of the Zynthian case significantly but predictably hot, about 40 degrees going from tactile impression.
Added contextual detail: very long powering off routine.
I notice you have the USB Type-B connector plugged in. Also the MIDI OUT. Can you reteset with these removed? (I may be clutching at straws but minimising the test scenario helps remove possible causes.)
[Edit] Also, will you paste your webconf dashboard screenshot here?
[Edit] Also, apply the updates. There may be a difference that you are experiencing that we won’t see because we have the updates applied.
And the video of terminal with “htop” running while producing the XRUNs.
Thanks
Hi 
No significant change with OS updates: maybe, just maybe, the problem seems a small tad worsened, with the red warning sign and the x-runs storm almost immediate (just one Surge chain loaded).
Only Midi 5-DIN IN used, OTG Midi and 5-DIN Midi Out disconnected.
CPU temp risen to 46.2.
See dashboard attached:
No time to record it now, but later will do.
Anyway, htop in terminal shows straight away drastic red lines on the 0123 cores, and red letters on some of the python or system routines involved.
BTW: is there a simple way to record a video from the terminal on my Mac? (I mean, apart from MacOS screen capture)
Thanks!
More straw clutching: try disabling WiFi.
Hi there,
There is absolutely no difference in performance or x-runs amount if Wifi is disabled…
Temperature still in the 43-46 degrees range.
See video attached, with terminal running htop (only Midi IN 5-Din connected to the Zynthian. Just in case, I also tried without ethernet cable connected from the external computer: no difference).
All the best
Well guys,
Now I have to seriously finish packing for holydays, and therefore the lovely Zynthian V5 will have to wait for my return.
Thinking about the potential CPU malfunction, and if any possible software issues are to be excluded, I have considered a few random ideas, which I am advancing here in no particular order:
1 - I have stumbled across a faulty Rpi4, and it is showing after a while of honourable service.
2 - A V5-specific component has become non-functional or less functional in time. My V5 is one of the very first released and sold, with arguably elements from the first batches of everything.
3 - I have managed to fry or degrade something in my Pi4 board or CPU, through usage. I have to say that it is not been particularly intensive, but I have spent quite a few (engaging) hours on an ongoing 16-channel project.
Anyway, I will try to flash a Stable on returning home, and see what happens under the same conditions and with the same example snapshots, just in order to clean the slate from the possibility that it is an Oram-related problem (which I reckon to be very unlikely).
Meanwhile, a huge thank you good folks, for all of your help and attention! 
I notice that jack is entereing long periods of disk sleep which is non-interuptable sleep, most probably waiting access to the audio / MIDI driver. I do not see this on my V5 when playing notes to Surge XT. This may be relevant.
Enjoy your holiday.
Thanks @riban,
I will get back to this topic in about twenty days, and in the meantime I will try to assimilate the possible technical meaning of your interesting remark
