Pianoteq 8 on Raspberry Pi 5

I completed my tutorial and published here. Any comment will be welcome

I'm testing just by my ears, do not have any special equipment to do it. If you may suggest better testing option with software it will be welcome.

The RT kernel makes really the difference from a very audible latency to a hardly detectable. As for the suggestion from this site, ref. my previous post:

1. I cannot detect any evident difference in latency, and no disturbance are there in the sound. I'm not however an expert player, therefore I cannot exclude that with more intense use some problem may rise.

2. Without cpufreq a lot of cracks disturb the sound

3. No apparent differences using this option. This option was created for the Pi 3, I'm not even sure if it is still applicable for Pi 5, I cannot find any module or overlay with such name.

Ciao Roberto.

I don't have a Pi5 at the moment, so I can not test your instructions, but they look really well written, comprehensive and accurate.

Thanks for doing that!

BTW same test on a Pi4B:

real    0m34,622s
user    0m47,624s
sys     0m4,530s

Large difference, but the latency in Pianoteq is comparable to Pi5. This test looks not so significant.

I did some more test and now I'm really confused.

I realized that I did not change the CPU governor in my previous test. I'm using cpufrequtils not cpupower (Q: is there any difference?). In my case the code is as follows:

# sudo cpufreq-set -g performance
# ./Pianoteq\ 8\ STAGE/arm-64bit/Pianoteq\ 8\ STAGE --version
Pianoteq STAGE version 8.4.1/20250204 -- [url]http://www.modartt.com/pianoteq[/url] Copyright (c) 2025 Modartt.

# time ./Pianoteq\ 8\ STAGE/arm-64bit/Pianoteq\ 8\ STAGE --preset "Shigeru Kawai SK-EX Ryuyo" --headless --play-and-quit

real    0m37.491s
user    0m32.700s
sys     0m1.315s

# sudo cpufreq-set -g ondemand

Which is surprising because it look worse than the test done with the governor set to ondemand, unles I'm not able to read these numbers. In fact I did another test with the governor set ondemand and the result were more similar to the result I got last time, even though not the same:

real    0m37.818s
user    0m28.599s
sys     0m1.048s

It looks like this test is not replicable, unless it needs additional preparation.

I did not mention that I did a trial installing a vanilla Bookworm with the RT 6.1.0 kernel package available in the distribution. The results (by ears) were better than standard kernel but not as good as those with the kernel 6.14.0 rc3 compiled by me.

Since last week i have a Stage license I'm using for my tests.  Today I tried again and the result was more logic:
ondemand

real    0m37.213s
user    0m27.061s
sys     0m1.020s

performance

real    0m37.189s
user    0m23.840s
sys     0m0.876s

I run also the test with top; the load of course was not stable, I tried to catch the highest:
ondemand

performance

In ondemand the load is considerably higher, even though I cannot understand exactly why.

Jari_42 this is the kind of thing trivial for someone, but not for me that I'm not familiar with these parameters. Thanks a lot for this precious hint.

My use of Pianoteq is very basic: I own a Stage licence, I use to perform for myself or a small audience and accompany my voice, no other sophsticated use or sound research at the moment. Therefore I believe the suggestion perfectly fit it as long as does not affect the sound of Pianoteq standard instruments.
I reduced the sample rate to 48k and the buffer to 192, now if I leave the local control of my piano On I cannot distinguish the sounds generated internally and by Pianoteq.

In fact with this new settings the use of CPU by Pianoteq incresed to 92% and also time is giving worst results:

real    0m37.720s
user    0m28.913s
sys     0m1.167s

The effort to compile the kernel is minor therefore it is stil worthy. I'll try different settings to find the best for me.

It is different for my brother that has a more professional use. He owns a Pro licence with internal sample rate 192k and Organteq licence. What I understood from him is that the difference between 48k and 192k comes mainly for recording purposes. At certain conditons he say that the Pi 5 perfectly fit his needs.

It reduce the CPU load and allow faster response, this is one point. When I have time I'll make a comparison between the performances of the 2 kernels.

There is another point I would like to clarify: by doing the tests mentioned in this thread it seems that there is not an advantage to reduce the sample rate and buffer size in term of use of resources and latency. The combination 192kHz/768samples has approximately the same result that 48kHz/192samples. Is there any other reason to prefer one above the other?

command:
time ./Pianoteq\ 8 --preset "Shigeru Kawai SK-EX with Strings Pad" --play-and-quit --headless

Multicore rendering max:
real    0m23.490s
user    0m23.813s
sys    0m1.475s
25.288 user+sys

real    0m23.492s
user    0m23.421s
sys    0m2.269s
25.69 user+sys

Multicore rendering on:
real    0m23.589s
user    0m20.982s
sys    0m1.105s
22.087 user+sys

real    0m23.490s
user    0m20.953s
sys    0m1.187s
22.14 user+sys

Should we now use multicore on instead of multicore max???
I don't know if its a general case as it seems to happen mostly when Pianoteq is stressed more. Indeed, my working theory is some threads must wait longer to access the cpu. More testing needs to be done. Could be just an anomaly. Can someone check for similar results using the real time kernel?

Ciao Roberto,

From these results it's absolutely clear that the realtime kernel with multicore on is the way to go. I had no doubts about it, but it's nice to see it confirmed in practice with your experiments, so thank you for doing them and for posting the results here. Why I had no doubts?

RT vs regular kernel: I'm sure this is clear to you since you started this conversation, but for others, the RT kernel is made in such a way that the "responsiveness" of particular applications is given priority. This is obviously what we want for playing music: Pianoteq running all the time at full throttle even if some other background service (e.g. checking for updates which most linux distro do from time to time) takes a very, very backseat

multicore on vs max: on tries to maximize throughput by putting processes in the most optimal core (which sometimes could be a non-free core if cache locality makes it more advantageous); max tries to maxime core utilization by scheduling processes in the most "spread out" way among different cores in the machine. IIRC, max also enables hyperthreading, which means uses more software threads than are available physical ones. I don't have a good grasp of the raspberry architecture, but on high end Intel and AMD this often "dirties" the cache, so cache coherence and cache locality can slow things down, even worse with hyperthreading. It can be a good solution in some very limited circumstances, but rarely so and on all my high performance machines it is never used (hyperthreading is off and multicore is on, not max)

After repeating the tests on a Pi4 I have to contraddict myself: multicore max is way better than on. The result of the tests shows the following:
multicore max

real    0m39,374s
user    1m21,624s
sys     0m4,306s

multicore on

real    0m52,045s
user    0m53,704s
sys     0m1,596s

in max mode some clicks or cracks appears, but in on the sound is badly interrupted and distorted. The device becomes unusable also for mild play. The RT kernel may improve the latency but has apparently a bad effect to for this problem, in max mode the disturbances increase with RT kernel (!). What looks like is that the system is already at his limit, I think Pi4 cannot be a good choice for intensive use.

I tested again the Pi5 trying to stress it with a lot of notes and sustain fully pressed: with on mode after sometime I may get disturbances appearing but in max mode I could not undermine it even with my best effort.