Hi @zynthianers and @jofemodo
I have a hopefully simple question: should Rpi5 appear overclocked by default in latest Oram?
Mine is not with latest OS release, and this seems to affect performance.
In my custom Pi5 Zynthian installation, there is no active overclock reported in webconf after updating. I wonder if this is by design, that is when Oram does not detect an official V5 kit with its specific heat dissipation system.
FYI, my enclosure features both passive and active cooling, so I surmise that it could manage some CPU speed raising.
Thanks!
No. Rpi5 is not overclocked by default, nor Rpi4. The autodetect system doesn’t know about your heat dissipation system, so it doesn’t overclock by default. If a V5 kit is detected, it would configure overclocking, but not for “custom” builds.
Of course, these are the defaults. You can configure your overclocking as you like, but please, note that if you exceed the limit, your system probably won’t boot and you should have to reconfigure by hand, accessing the disk and modifying the config.txt.
In my experience, all RPi5s support overclocking to 2700 (medium) and almost all (i found a single unit that failed) can be overclocked to 3000 (maximum). I discovered the failing unit because it simply didn’t boot. At first i though it was the firmware issue that was causing trouble again. I waste 2 hours until i discovered that the real cause was that this unit failed when overclocked at 3000.Now it’s working smoothly at 2700. Of course, all my RPi5 are firmly attached to a V5 thermal-block. Don’t try overclocking RPi5 without a good heatsink!
Regards,
3 Likes
Thanks @jofemodo, both for your breakout of the webconf underlying rationale in the overclocking area and for the effort, in investigating the matter hands-on with various Rpi5 units at different CPU speeds.
Now it makes perfect sense that Oram does not set overclocking by default, if it detects a custom build.
I will then try cautiously to start overclocking at the first medium step, and see what happens.
At the moment, my only performance qualm with Pi5 at base clock would be using Pianoteq at full sample rate, and building extended fx-laden snapshots with large soundfont libraries.
If this weren’t the case, I will always be able to share the sonic burden among the other Zynthians and synthesiser gear
Hi Aethermind,
As a Reference I have Pianoteq running on Pi5 with 48k and buffer size 128 without overclocking. No xruns and totally stable. But I have no other effects or sound modules running in the snapshot. I need to still consolidate my snapshots into zs3’s so I’ll possibly get to see where the limit is
1 Like
I can also confirm that experience.
1 Like
Hi @chrismat!
I too have used Pianoteq at full sample rate with 128 voices, on a previous Oram Pi5 installation at base clock, together with a few other chains of both synthesizers and samplers.
Not a glitch, but now after updating to latest it seems that Pianoteq tends to clog the audio buffer. It may well be a matter of imperfect installation of some new components of the underlying Raspberry OS, or of something gone south in the instrument binary.
I will investigate
Best regards
1 Like
Is it not a problem of the soundcard? I have often had problems with many USB soundcards. (Or it was a problem of the computer/SBC (its USB implementation) or just the combination of both.) Often rather random issues.
Hi! I doubt it, because the DACs of the audio board just take care of translating strings of bytes churned by the CPU into micro-electrical levels, thus transferring waveforms from the “stepped” world of digital numbers to the continuous analog reality of voltage and amperage.
My Hifiberry 8X card is more than capable of managing fluently large amounts of data, but for the sake of thoroughness I will have a try at reverting briefly to my good and proven Presonus USB interface.