I like the look, but it may be possible to run fan-less.

I also think it is. I installed it because I paid less than 5 euro and power is not an issue.
However despite the relatively close case I'm using I've never seen the fan starting, and even after intense use the CPU temp never overcome 55°C.

Re fanless, I've configured things so the fan only kicks in as a last resort thermally in my setup. Ironically I possibly have to protect the PLA-3D-printed case more than the Pi itself, since PLA as a material is only really good for around 60C. Still, usually the fan doesn't come on and I'm fine.

Edit:
I should have said throttling should kick in before 70C. My basic point though is it should be possible to run fan-less. Some pi5 cases are designed specifically for this purpose. Including a hat might make things a bit more difficult and some case claims may be unjustified. Buyer beware.

... to get a newer PipeWire stack with improved JACK support...

My approach was to keep the use of resources as low as possible: headless device, no DE, no graphic tools whatsoever. VNC + X11 are enough to get the Pianoteq graphic working for setup, showing the interface on my mobile or a tablet. To perform with fixed preset I also prefer the headless mode that eliminates also VNC and X11. Raspberry SSH android app is great to send commands with a button.

I do no see the advantage using Pipewire or Jack to send audio output, Alsa is more than enough. What is your experience?

Very cool to encounter a couple of other Linux/RPi5 users of Pianoteq on this forum!

Likewise (I'm still on the work-in-progress stage)

Thanks for sharing your projects (I browsed your website and found quite a few ones, some very sophisticated, congrats!)

I also did a similar build last year, but decided to use Fedora Linux instead of RaspberryPiOS to get a newer PipeWire stack with improved JACK support in place. It's running quite well for me with 48 Khz, after doing some of the usual optimizations (realtime scheduling/priorities, etc.).

As DAC I chose the Scarlett 2i2 4th gen, mainly due to this excellent project. I CAD'd up and 3D-printed a custom black chassis for it to make it fit in more nicely with the beautiful VPC1, and another one for the RPi5.

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.

jari_42 wrote:

That's great to know, thank you very much.

I switched between standard kernel and RT enabled kernel and I may say that with your setting the difference is negligible. Even increasing the buffer size to 384 the second kernel has not significant advantage, therefore I think I also will switch back to the standard kernel to use my STAGE version. May be the advantage is only visible with Pi 4 and/or PRO version with 192 kHz, I will keep testing when possible.

levinite wrote:

Should we now use multicore on instead of multicore max???

I did not know that the multicore option can be set differently than max. Options are not mentioned in the README file or in the manual and does not even appear in the "help" text.
I did some test too ( each test was repeated minimum twice), with standard kernel and with the output set to 48kHz and 192 samples I got larger differences, and looking at the CPU usage of Pianoteq I found approx 30% difference between the two multicore rendering:
multicore max

real    0m37.803s
user    0m29.324s
sys     0m2.349s

CPU 98% max

multicore on

real    0m37.826s
user    0m23.190s
sys     0m0.442s

CPU 68% max

Changing to RT kernel there are comparable differences but with much lower stress levels:
multicore max

real    0m36.989s
user    0m21.089s
sys     0m0.847s

CPU 66% max

multicore on

real    0m36.985s
user    0m15.407s
sys     0m0.310s

CPU 44% max

Playing musics I did not hear any disturbance. I think I'll keep using the on mode. Anyone may point out disadvantages doing it?

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)

That's great to know, thank you very much.

I switched between standard kernel and RT enabled kernel and I may say that with your setting the difference is negligible. Even increasing the buffer size to 384 the second kernel has not significant advantage, therefore I think I also will switch back to the standard kernel to use my STAGE version. May be the advantage is only visible with Pi 4 and/or PRO version with 192 kHz, I will keep testing when possible.

I did not know that the multicore option can be set differently than max. Options are not mentioned in the README file or in the manual and does not even appear in the "help" text.
I did some test too ( each test was repeated minimum twice), with standard kernel and with the output set to 48kHz and 192 samples I got larger differences, and looking at the CPU usage of Pianoteq I found approx 30% difference between the two multicore rendering:
multicore max

real    0m37.803s
user    0m29.324s
sys     0m2.349s

CPU 98% max

multicore on

real    0m37.826s
user    0m23.190s
sys     0m0.442s

CPU 68% max

Changing to RT kernel there are comparable differences but with much lower stress levels:
multicore max

real    0m36.989s
user    0m21.089s
sys     0m0.847s

CPU 66% max

multicore on

real    0m36.985s
user    0m15.407s
sys     0m0.310s

CPU 44% max

Playing musics I did not hear any disturbance. I think I'll keep using the on mode. Anyone may point out disadvantages doing it?

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?

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.

That's great to know, thank you very much.

You're doing more computation than necessary with 192kHz/768samples as you're upsampling the internal sample rate of 48kHz up to 192kHz and you're unlikely to hear any difference, although as you say there are some applications such as recording where it may be desirable to have a higher sample rate for mastering/postprocessing headroom.

Do you still see an improvement with the RT kernel using a 48kHz sample rate and 192 buffer?

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?

I agree, no need to change sample rate and a smaller buffer and higher polyphony may work but If he uses morphing or layering he may want to change it back. Organteq already requires more resources than Pianoteq and some presets overload my pi5. Smaller buffers always require more resources. Personally, I choose the largest buffer which allows for an acceptable latency. Using his kernel patch might allow him to keep the buffer larger.

Agreed, I don't use morphing or layering but that would significantly increase the resources required.

Do you still see an improvement with the RT kernel using a 48kHz sample rate and 192 buffer?

but If he uses morphing or layering he may want to change it back.

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.