Pi 4 / Sample rate / Pianoteq config changes

Hi There! My old forum account is not woking anymore… nevermind - made a new one.

Got a question for you folks :slight_smile: OK to be honest its a bunch, and maybe a suggestion?

But first my story:
I started with an older Zynthan Kit build upon a Pii 3. Then after a while Pianoteq did join the club and as soon as it was available I bought an Pii4 for improving the Pianoteq performance.

Since then I am quite happy with it and having the following settings works perfectly for my combination of Pii4 and Hifiberry DAC+:

-P 70 -t 2000 -s -d alsa -d hw:sndrpihifiberry -S -r 48000 -p 256 -n 2 -X raw

I even can choose 48000 as an internal sampling rate for pianoteq:
grafik

This is quite a big thing when it comes to audio quality, I can just recommend to try it yourselves :slight_smile:

So far so good. So based on this:

Is it possible that overall sampling rate has been chosen with Pii 3 in mind?
If that is the case, maybe having different settings for Pii3 and Pii4 could provide a better experience for Pii 4 users?
(Please keep in mind that an increase in sampling rate lowers latency with same buffer size - so it is not “only” sound quality)

Every time I reboot the zynthian Pianoteq`s internal sampling rate is back to 24000.
So I did modify the “zynthian_engine_pianoteq.py”. This helped up to the point of the next time I did ran “Update” for the zynthian.

Is there a better way to keep my pianoteq settings while being able to fire and forget the updater?
Could it make sense to think about it the same way differently for Pii3 and Pii4?

Thank you for reading, maybe you have some advice for me?

Regards,
Martin

Hi Martin. Even the RPi4 struggles with an internal rate above 24000. It will soon trigger xruns with clocks on audio. A RPi4 can run PianoTeq at the higher internal rate but there is an issue with doing so in Zynthian.

Hi riban, thank you for your Answer! By the way I am a big Fan of what you are doing here, thank you!

I tryed to get xruns with 48000 internal sampling rate by pressing all the keys and it seemed to be OK. For a more steady test I did use Pianotecs demo song (the one you can trigger by pressing "play" in the UI) and the load shown in Pianoteqs UI was between 50 and 70% (depending on the Instument - for example the Rhodes did use less CPU). I could not hear crackeling or noise of any kind. Even using the sustain peadal did wok perfect.

In order to get xruns I needed to lower the buffer size to 128.

Maybe the latest version of Pianoteq did improve performane? Maybe I am doing something wrong?

This is interesting. There haven’t been updates to Pianoteq since I last tested this but you are right that it does seem to be working better. This may be the result of various optimisations we have done to Zynthian over the past year. My tests involve holding the sustain pedal whilst performing glissando and watching the performance graph in Pianoteq settings and monitoring jack cpu load. I observe today that with polyphony limited to 32 notes and internal sample rate set to 44100 (the sample rate my Zynth is currently running) and 256 samples per buffer. I could play all 32 notes without hitting the limit. I saw brief peaks for 72% jack CPU usage but no xruns. This is good news and we can look at adding a configuration for this setting. Some users may still prefer the lower sample rate, e.g. if they have other resource hungry engines running. We could also add the polyphony as an option.

I did see CPU load hit the roof (99.25%) and observed xruns when pushing the LV2 plugin. It looks like LV2 has greater overhead than native version.

I noticed that the LV2 presets are broken (not available) for the LV2, possibly related to detection of the instrument due to change of version. We need to look at that.

This was all done with image 2210-staging which overclocks the RPi to 2GHz which will help with CPU load.

Actual CPU usage was evenly distributed across the 4 cores rising with concurrent (polyphonic) usage.

[Edit] Also enabling VNC will affect resource usage because with VNC enabled the GUI version is run but without this the headless version is used which requires lower CPU / RAM. My tests today were with VNC enabled.

6 Likes

Thank you for checking :slight_smile:

So I guess this is great news for everyone!

1 Like