Modartt user forum - Pianoteq headless as service

Re: Pianoteq headless as service

null@example.com (jimmi) — Wed, 26 Mar 2025 03:28:39 +0000

levinite wrote:

A setting of infinity sounds dangerous...there must be a better way!??

I did not paid attention to the README file from the developers, my bad. In that file the suggestion is:

@audio - rtprio 90
@audio - nice -10
@audio - memlock 500000

therefore I modified the service file as follows:

[Unit]
Description=Pianoteq headless

[Service]
Type=simple
User=pi
LimitRTPRIO=90
LimitNICE=-10
LimitMEMLOCK=500000
EnvironmentFile = /home/pi/Pianoteq\ 8\ STAGE/arm-64bit/preset
ExecStartPre=/usr/bin/sudo /usr/bin/cpufreq-set -g performance
ExecStart=/home/pi/'Pianoteq 8 STAGE'/arm-64bit/'Pianoteq 8 STAGE' --headless --multicore max  --preset $PS
ExecStopPost=/usr/bin/sudo /usr/bin/cpufreq-set -g ondemand

[Install]
WantedBy=multi-user.target

Also KillMode=process is wrong here, removed. Looks better now

Re: Pianoteq headless as service

null@example.com (levinite) — Tue, 25 Mar 2025 23:58:06 +0000

A setting of infinity sounds dangerous...there must be a better way!??

I notice the real-time scheduling error 1 when the audio privileges are not set and multiple core or at least when multi-core max is set in Pianoteq. I think what it means is Pianoteq requires rt privileged settings because internally it calls the OS to set its threads rt privilege levels.

Pianoteq headless as service

null@example.com (jimmi) — Tue, 25 Mar 2025 06:17:19 +0000

I've seen this approach proposed years ago in this forum. Recently I reviewed it with a slight different setup on my Raspberry Pi 5 headless, to be managed by buttons of an external Android app. I want to share it here to listen eventual comments or suggestions. The service file is the following:
pianoteq.service

[Unit]
Description=Pianoteq headless

[Service]
Type=simple
User=pi
LimitRTPRIO=infinity
LimitMEMLOCK=infinity
LimitRTTIME=infinity
EnvironmentFile = /home/pi/Pianoteq\ 8\ STAGE/arm-64bit/preset
ExecStartPre=/usr/bin/sudo /usr/bin/cpufreq-set -g performance
ExecStart=/home/pi/'Pianoteq 8 STAGE'/arm-64bit/'Pianoteq 8 STAGE' --headless --multicore max  --preset $PS
ExecStopPost=/usr/bin/sudo /usr/bin/cpufreq-set -g ondemand
KillMode=process

[Install]
WantedBy=multi-user.target

I found that calling cpufreq-set only once without the option -c sets the governor to all the cores automatically.

When I first used this service I found several messages in the logs similar to these:

...
Midi thread could not acquire real-time scheduling, error 1 -- Operation not permitted
Alsa thread could not acquire real-time scheduling, error 1 -- Operation not permitted
Multi-core: could not acquire real-time scheduling, error 1 -- Operation not permitted
...

Apparently it was not causing any problem, but digging in the web I found that the system does not complain anymore if I set the LimitXXXXXX=infinity as in my file. I learned that this is related to realtime scheduling, but I cannot understand the possible implications of it. Anyone knows if there coud be unwanted side effects?

In order to change the preset I then create a series of scripts similar to this:

#!/bin/bash

echo "Starting Pianoteq headless:" ; echo "HB Steinway D Classical"

# Overwrite the variable declaration in the preset file
echo "PS=\"HB\\ Steinway\\ D\\ Classical\"" > /home/pi/Pianoteq\ 8\ STAGE/arm-64bit/preset

# Start Pianoteq headless service
sudo systemctl restart pianoteq

and associate each script with a button so that I may change the instrument easily without accessing the graphic interface. What is your thought about this?