Pianoberry – Pianoteq 8 @ 1.33 ms latency on Raspberry Pi 5

Weird that you couldn’t get the same performance as me - given we’re using such similar systems. I’m using a 96K sample rate, but with an ‘internal sample rate’ of 48K, which I think is what PT (Pro) defaults to if you switch to 96K. I have in the past tried switching to 96K internal rate but couldn’t hear the slightest difference so now don’t bother. I’ve left polyphony on the default of 48 and am currently seeing a ‘performance index’ of about 70.

I’m sure the PT sample rate figure is correct in its own right. I’m just not sure what exactly it might correspond to in the real world. That’s why the approach I took before was to measure latency between onset of key strike noise and onset of sound from the loudspeaker. The idea was to take in the whole chain to arrive at a figure which might correspond to how the thing felt to play.

I.

Hi there.

I’m trying a new install of Pianoberry v1.1.0 onto a raspberry pi 5 (4gb) with a pisound board connected - and I’m drawing a blank. (I also have the Raspberry Pi Active Cooler kit on)

I followed the instructions to flash pianoberry.img.zip onto the micro SD card
(I found I did have to unzip it, otherwise Raspberry PI Imager writes the .img file onto the card as a single file)

When I then insert the microSD card into the Pi 5, the status light goes Red, then Green, then after a few seconds the LEDs on the PI Sound flash once.

I then connected a USB midi keyboard (I’ve tried 2), and I don’t get any sound out?

Because it’s headless - I’m not sure what to do next?

I tried flashing the microSD card with Raspberry Pi OS, and it boots fine with that?

Any help appreciated.

This should definitely not be needed. Open Raspberry Pi Imager (v1.8.5 or later), click “CHOOSE OS” and click “Use Custom”. Flash without setting anything else, we just want to flash the image to the SD card.

This is the error right here. Pianoberry is set up to use the MIDI port like it says in the readme and in the release notes.

  • Rune

Pianoteq has a “Listen to all MIDI inputs” option, this should allow it to listen to both USB MIDI and Pisound MIDI input.

Hi Elektrofon,

Thanks for your reply.

Apologies — you’re absolutely right, and you even mentioned it in an earlier message: the pre-built image is set up to receive input from the Pisound MIDI In. Connecting a USB MIDI keyboard is possible, but it requires rebuilding Pianoberry.

I installed Pianoteq for Linux with the intention of exploring how USB keyboards are defined, but we got a bit sidetracked trying out different pianos.

In the end, we concluded that we’ll want access to the Pianoteq UI, so we’ll be going in a different direction.

That said, I did rebuild the Pianoberry image with a few configuration tweaks — and I have to say, I’m a big fan of your Docker-based build system. I’m definitely adding that to my bag of tricks!

Best wishes

1 Like

I’m very interested in purchasing a Pi 5 and Pisound hat to use with Pianoberry. However, the Pisound is currently out of stock, while the Pisound Micro is available. I don’t mind doing a little soldering so that I don’t have to wait for the regular Pisound to become available again.

Does Pianoberry work with the Pisound Micro out of the box? If not, is it straightforward to modify it to make it work, and are there any instructions available for doing so?

I haven’t tested the Pisound Micro, but with a few tweaks to the Pianoberry build script(s) it should work. If there are instructions depends on what your definition is and where you are coming from in terms of experience. The readme is all there is except the source code. All of it is open source on GitHub.

Hi ! Pretty interested in getting a Pi 5 to test this !

ATM I use my main Linux PC for Pianoteq but, as expected, it turned out I cannot focus with a computer constantly turned on…

I used to have a Roland Verselab (synth - sequencer - recorder) but was frustrated by the piano patches which are made of… FOUR SAMPLES ! (sounded good but lacked expressiveness, of course !). At least it enabled to make everything without a computer. Oh well.

A question : can I set it up easily (without recompiling, just by editing a config file) to change instruments / presets with MIDI CCs ? Would be nice to have it enabled by default ?

I see you report a 1.33 ms latency. I made some tests on my PC, and there could be a huge gap between the reported latency and the actual round trip latency. Well. More or less depending on the sound system and profile used. For instance, using the “Pro audio mode” of Pipewire was more effective than reducing the number of buffers (to some extent). I guess you use direct ALSA so that should be optimal !

ATM on my PC I settled with a 12.5 ms roundtrip latency (reported as 5ms in Pianoteq) with 256 buffers, 48 KHz. I used this value after tons of testings because it also works perfectly in Bitwig or with Arturia Analog Lab V (through WINE/WINEASIO). I am not sure I can feel the latency at this level. — But it was worse in non “pro audio” mode. For instance, with 128 buffers, I had a 25 ms roundtrip latency. – half the buffers, double the latency !

Thanks a lot ! :slight_smile:

Edit : oh, by the way, how much time does it take for Pianoberry to start ?

Hi @bidinou !

Limiting distractions and mimicking the immediacy of a real acoustic instrument is why I wanted to build this for myself. The end goal is a piano that I can sit down at and play, which feels like and sounds like the real deal without the practical challenges of a big piano.

Changing presets is not implemented yet, and I don’t think I want to focus on that for the Pianoberry project. I think of Pianoberry as a foundation to create standalone instruments; a good place to start from. It is made to be tinkered with and compiled by the user/instrument builder.

Latency can mean different things depending on how much of the chain you account for.

The latency reported by Pianoteq is mathematically accurate, but it only accounts for Pianoteqs internal processing, from when a control signal comes in and the audio sample is handed over to the audio hardware.

The concept of round-trip latency does not apply to Pianoteq as it is synthesizing sound. There is no sound input being processed and relayed. We talk about round-trip latency when measuring digital converters.

I guess you perhaps talk about latency from when you hit a key on your master keyboard to the sound coming out of the speaker. This depends on a whole range of variables.

The only thing I can tell you for a fact is that Pianoteq at the config I’m running has 1.33ms latency. To get real world latency you have to account for MIDI latency (1ms+), OS MIDI latency (0-100ms), OS audio latency, external processing latency (DSP in active speakers or amplifier) and how far you are from the sound source.

I’m only in control of latency from the MIDI socket on Pisound to the audio output on Pisound. There can be a lot of latency added before or after.

The best MIDI controllers have around 1ms input latency, anything below that is basically not possible. USB MIDI, if ran on USB High Speed (USB 2.0) has the potential of running much faster, but USB MIDI is most often ran on USB Full Speed which functions on a 1ms polling interval from the USB host, giving a practical latency of ~30µs to 1ms. DIN MIDI is limited by its baud rate but is at least providing consistent latency – which is why I set up Pianoberry to use DIN MIDI and not USB.

Pianoberry is built on Tiny Core Linux. Tiny Core Linux decompresses from disk (SD Card) to RAM on every boot. This decompression takes a little bit of time, but given the incredible tiny size of the binary it results in just a few seconds boot time. It would be possible to achieve faster boot times on a different OS, but the upsides of having the whole stack run from RAM far outweighs the slight increase in boot time.

Wondering if anyone can assist with what might be a simple problem. I’ve got a few extra instruments in my Pianoteq account, so when I download and try to add the binary to the SD card it’s too big. Anyone have any pointers on how I might fix this?

Welcome @Mrsuitcase!

The image size and partitions are set up here:

Hello, I’m in a similar situation as Mrsuitcase, my pianoteq downloaded file has a few instrument and doesn’t fit with the partition on the SD card as formatted. I see the previous note on where to change the image size and partition, but I am not a programmer and don’t know how to use and compile any / all the files that are posted on github. Don’t know if it’s too much to ask if you could increase the SD card partition size so the pianoteq file will fit. It’s a small change but I simply don’t know how to use the appropriate tools. Thanks in advance for any assistance.

Hi and welcome @peter810!

The build instructions are at the bottom of the readme. I have tried my best to make it as simple as possible. All you need to install before running the ./build command is Docker. Docker is a normal application that you download and install like any other.

I urge you to try. Getting this to work will open up so many doors. I guarantee you that it’s just fear that is holding you back — don’t let it :slightly_smiling_face:

2 Likes

Hello,

Thank you Elektrofon for this project !

I still can’t get any sound out from my box :frowning: ; after few days of trials, I’m stucked and requesting some help.

I have a pi5 + a new pisound (hw 1.2) I ordered for this project.
The first try with the released image gave no sound ; then I tried to rebuild an image with my pisound cardID in the Pianoteq84.prefs (PS-XXXXXXX).
Still nosound (I can see midi event on input but no audio).
I put the Pianoteq 8 binary (64bit) into the pianoberry folder (beside Pianoteq84.prefs and startup.sh).
Still no sound.
I realized that the Pianoteq 8 binary was missing in the /usr/bin for unknown reason.
Then I tried to put the binary at the root of the pianoberry.img as recommended.
I had to extend the img size with dd within the build script:
dd bs=512 seek=512000 of=pianoberry.img < /dev/null
parted --script pianoberry.img
mklabel msdos
mkpart primary fat32 8192s 256000s
mkpart primary ext4 256001s 100%
This allows to put the binary in the img. I can now see the Pianoteq 8 binary in the usr/bin + correct pref in root/.configure/Modartt
but still no sound:-(

I tried everything I could to avoid to bother you with such messge but I have no more idea and need your lights.

I still hope to hear piano sound soon :slight_smile:

Nico

Hi and welcome Nicolas!

The problem you’re having is most likely due to a mismatch in pisound device address.
As other users have mentioned there is a new version of the pisound board which has a different designator (file path in Linux) than the old version which I have.

There is an open issue on the Pianoberry GitHub page about it that I unfortunately haven’t had the time to look at yet.

My suggestion would be to check out the solution provided in that issue.

When I get the time to look at it I’m going to see if there is a way of solving this automatically by implementing a more dynamic device lookup.

Just as a test, could you try using hw:pisound in the prefs file instead of the very long device name? I’m not sure if Pianoteq accepts it, but it’s a generic way to refer to a Pisound in ALSA world. The same value should work for ALSA RawMIDI ports too.

Good call @Giedrius I will definitely try this!

Thank you Elektrofon for your quick reply.
Yes I saw the issue and the proposed fix.
I tried it by replacing the Pisound Device ID in the Pianoteq84.prefs as recommended. I can now see the correct ID but this doesn’t solve my sound issue…
There’s certainly still something wrong in what I did.
I will retry around and ask on the open issue if still stucked.

Thanks for the suggestion.

Btw, Nicolas, did you get sound out of your Pisound otherwise using a regular OS image? Just to make sure that it has not malfunctioned?

I haven’t tried yet but it is a good hint I wanted to do. Thanks for the advice.