Sooo ... vcgencmd get_throttled gives me 0x0 every time. I did see that most of the time, only 1 core is maxed out at 100%.
I also get some messages: "note dropped, queue full" and "output buffer underrun"

Okay, it's likely an issue with optimizations, then.

Yeah that's what I figured. I'll take another look at the detection script and see if it's choosing the wrong settings

Thanks for the pointers about the Pi2's limitations guys. I just got a Pi3 for relatively cheap and was going to replace my Octopi server with it. But if the Pi2 is working okay as a print server and it might also struggle with Munt, I'll use the Pi3 instead 😀

Me and DonZott are working on he Pi2's performance right now, so hopefully we can get it running. But I would suggest to use a Pi3 or better anyways as it'll still run better on the 3/4 even after we fix the compilation issues.

Exactly. The Pi 2 can do the job, but the Pi 3 has a lot more performance potential. The Pi 4 is undoubtedly the best option, though, as more RAM can really pay off with big (huge) sound fonts.

DonZott wrote:

Sooo ... vcgencmd get_throttled gives me 0x0 every time. I did see that most of the time, only 1 core is maxed out at 100%.
I also get some messages: "note dropped, queue full" and "output buffer underrun"

-

Hi,
the Munt core library currently is single threaded so it cannot benefit from multiple cores. Compiler optimizations have nothing to do with this. Munt requires a rather high IPC single core. Currently for using multiple cores you have to segment the single 9 channel domain to multiple parts and assign them to independent instances of Munt running in independent threads. That's what MuntVSTi currently does but only in 16-channel mode (2 channel domains). More info about why Munt is currently single threaded by Serg:
Re: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi

Also by default Munt uses integer rendering (that is much more faster than the relatively new floating point rendering code path) so enabling advanced floating point support compiler switches (Neon/vfpv4) results in no substantial benefit.
Neon/vfpv4 can help in case of floating point rendering (just like SSE2 on x86) but using floating point rendering mode of Munt is not realistic at all on Raspberry Pi 2. It can even kill 2GHz+ x86 CPU's in some cases.
The only real pragmatic approach for weaker CPU's is to decrease the maximum active partials of Munt. Performance of Munt is directly proportional to active partials. Of course fewer than 32 maximum partials can result in observable polyphony problems. But it's still better than stalls and randomly dropped notes. Try e.g. 24.

- reverb and chorus enabled => disable them

I do not think this will work with Munt on Raspberry Pi 2 to get better performance. It's because Munt (just like real hardware) does not support Chorus effect at all 😀
Also Reverb works completely differently compared to later GM/GS modules (there is no support for CC#91) and disabling wet output completely results in very much reduced experience.

Falcosoft wrote:

Neon/vfpv4 can help in case of floating point rendering (just like SSE2 on x86) but using floating point rendering mode of Munt is not realistic at all on Raspberry Pi 2. It can even kill 2GHz+ x86 CPU's in some cases.
The only real pragmatic approach for weaker CPU's is to decrease the maximum active partials of Munt. Performance of Munt is directly proportional to active partials. Of course fewer than 32 maximum partials can result in observable polyphony problems. But it's still better than stalls and randomly dropped notes. Try e.g. 24.

Thanks again for the help. I never realized that you just ran multiple instances of munt to multi-thread it. I think that's a hilarious and brilliant solution!
I'll implement some sort of adaptive polyphony code, like I did for fluidsynth and see if that fixes things. Probably something simple that just checks what version of pi it's on and limits the partials accordingly.
I guess I could try a similar workaround in order to multi-thread it, but that's gonna have to wait a long while, as I have a lot of other things to work on first.

Your program is basically what inspired me to make this project. Well you and Phill's Computer Lab.

OK, I got some progress for the project.
I haven't fixed the Raspberry Pi2 stuff yet, but I was able to get a flashable WavePi installer Image working!!
https://github.com/t9999clint/WavePi/releases/tag/v0.8.1

In the 7z is a 1gb image that you can flash to any sdcard (min 4gb) and it'll detect your raspberry pi version and compile everything to match it's hardware. Please beware that it's very S L O W at installing, and not 100% automatic yet. You have to choose Yes once when it's installing jack2.

It won't install without a ethernet cable inserted into it. (no way around this sadly)
Default user is dietpi
Default pass is wavepi

it'll also show up on the network as "WavePi" and it has ssh and ftp enabled and preconfigured.
I recommend using etcher to burn the image to a sdcard. (Mac, Win, Linux)

Anyways I'd like you guys to test this out and let me know how it works for you.
If it works then I'll add this method to the official instructions. (It's WAAAY easier!)

Look what just arrived today.

The LCD is perfect. On the picture the background looks blue, but in person it's more black.

I only had to change the config from 16 to 20 columns. The I2C module that was supplied was already soldered onto the LCD. Everything worked out of the box.

I will design a new housing for this LCD this weekend and will hopefully also implement the push buttons. 😁

By the way: As this is a 5V LCD module I used a voltage shifter to connect it to the Pi as the Pi needs 3.3V. Not sure if you can get away without using one.

Nice, mine did also arrive today 😁

I've attached a raspberry pi to the midi out on the sound chip in one of my laptops (through a level shifter). My plan is to embed it into my laptop.

YouTube vid:
https://www.youtube.com/watch?v=Fsh5WeWt6kU

It's struggling with larger soundfonts (Timbres of Heaven is around 470 meg) but I'm impressed, nice work.

Which raspberry Pi model is that one? I don't recognize it.
If I knew the specs I might be able to give you a few pointers on what to change to get timbers of heaven working better.

t9999clint wrote:

Which raspberry Pi model is that one? I don't recognize it.
If I knew the specs I might be able to give you a few pointers on what to change to get timbers of heaven working better.

It's a Pi 3 A+. The killer is it's only got 512 megs of RAM. I'll switch to the Pi 3 B+ to get 1 gig ram. I probably can't switch to the Pi 4 due to current draw requirements.

CPU is the same between the A+ and B+.

furan wrote:

It's a Pi 3 A+. The killer is it's only got 512 megs of RAM. I'll switch to the Pi 3 B+ to get 1 gig ram. I probably can't switch to the Pi 4 due to current draw requirements.
CPU is the same between the A+ and B+.

Ram isn't the issue. If it didn't have enough ram it wouldn't load the soundfont at all.
If it's the same CPU as the 3B+ than I'd recommend putting a heatsync on the cpu and changing the polylimit multiplier I have set in line 22 of soundfont.sh
I'd recommend changing the 75 to something like 100 and see if that makes a difference.
I have it set fairly conservatively to help the RasPi 1 & 2 get by.

Let me know if that helps out at all.
Also feel free to contact me on Discord if you'd prefer to talk on there

RAM is an issue for me - this large soundfont doesn't always load when switching between them - sometimes the fluidsynth process dies when trying to load it. Will try out a heatsink after I switch to a bigger Pi - thanks.

furan wrote:

RAM is an issue for me - this large soundfont doesn't always load when switching between them - sometimes the fluidsynth process dies when trying to load it. Will try out a heatsink after I switch to a bigger Pi - thanks.

Ok then yeah ram might be an issue still.
It's possible that it's not quitting out the last running fluidsynth process quick enough. I have a idea on how to put in a workaround for that.

Try replacing the wavepi.sh in the scripts subfolder with this one...
https://github.com/t9999clint/WavePi/blob/mas … ripts/wavepi.sh

That should make switching profiles more reliable

After further long term testing, I'm running into a LOT of bugs with fluidsynth. So many that I wouldn't really consider it usable with soundfonts over 50mb.

I'm probably going to add a script to the installation process that will download a n build a newer version.
Since I'm compiling it now instead of just installing from the depo's, does anyone have any ideas for ways we can improve the performance of fluidsynth?
It's working great performance wise right now so It doesn't really matter, but if anyone has any tips I'd really appreciate it.

1sudo apt install libgtk2.0-dev
2
3mkdir tmp
4cd tmp
5wget https://github.com/FluidSynth/fluidsynth/archive/v2.0.7.tar.gz
6tar xzf v2.0.7.tar.gz
7cd fluidsynth-2.0.7
8mkdir build
9cd build
10cmake ..
11make -j 4
12sudo make install
13cd ../../..
14sudo rm -R tmp
15

I'm also researching an option to add a BassMidi option. Kode54 has already showed me some of his old code for this. It's not at ALL GPL friendly, so this would be as a addon pack. IF I do decide to make it.

New beta version is released. Here's the updated ras pi image.
https://github.com/t9999clint/WavePi/releases … WavePi.0.9.0.7z

I think the next thing I'm gonna work on is a updater script...