RAM requirements?

[rhester72]

I see this in the README:

There are also some caveats with large SoundFonts and Pi models with low RAM - see the FAQ for notes on this.

but I can't find a corresponding FAQ entry for it, nor an idea of what a "Pi model with low RAM" is. Any clarification on these caveats? I'm specifically asking because the Pi 4 has notoriously long boot times, and I'm coming around to the idea that the 3B+ may be plenty powerful for mt32-pi in terms of CPU and RAM while significantly reducing boot lag.

[dwhinham]

Ahh, thanks for pointing this out. There was an FAQ entry until yesterday, but I removed it, and I've forgotten to remove this comment too. I'll fix that.

Basically, in previous versions there were two problems related to SoundFonts:

1. Unloading SoundFonts was broken because of a FluidSynth bug which has now been fixed after I reported it: SoundFonts cannot be unloaded if polyphony is ever exceeded FluidSynth/fluidsynth#727
2. Circle's memory allocator has some limitations that make it less-than-ideal for large, varying allocations of memory at runtime, like the sort that happens when SoundFonts are unloaded and loaded. This means that "bin sizes" have to be decided up-front; e.g. 32K, 64K, 1MB, 4MB, 32MB... and anything larger than the biggest bin can be allocated, but never reclaimed again. With this model it's impossible to find an optimal bin size because SoundFonts can be only a few MB in size, or a few hundred MB.

At the time, neither of these problems had been solved, so I advised users in the FAQ to avoid switching SoundFonts too often or the Pi would hit an out-of-memory condition and crash.

The Pi 3A+ has only 512MB of memory, and it was very easy to run into this problem if you bounced between two 200MB+ SoundFonts, for example.

Problem 1 has been solved upstream as mentioned, and I have integrated their fixes as patches that get applied to FluidSynth v2.1.5 before mt32-pi is built. This means that FluidSynth now tries to release its memory properly when asked to unload a SoundFont. However, as of today FluidSynth v2.1.6 has been released which means I can remove the patches and fast-forward to the new version - this will happen very shortly.

Problem 2 has been solved by doing what many video games do: introduce a custom memory allocator which grabs a large chunk of RAM up-front at startup, and hand out chunks of this region to various subsystems. In our case, FluidSynth is the only component that uses this custom allocator. This way we avoid the limitations of Circle's allocator.

Fun fact: the custom memory allocator is based on the Doom "Zone" memory allocator - I used it in a video game I wrote a few years ago and I've resurrected it for mt32-pi. 🙂

The upshot is that you should now be able switch SoundFonts as many times as you like without memory being leaked and mt32-pi crashing. Also, other FluidSynth users (e.g. on desktop) who use the SoundFont switching functionality will no longer suffer from memory leaks.

So now, the only thing to consider is how large a SoundFont you plan to load. If it's greater than ~480MB, the Pi 3A+ doesn't stand a chance, so you'll need a 3B+ with at least 1GB.

Having said that, the size of a SoundFont shouldn't be the only indicator of its quality. GeneralUser GS is a mere 30MB and sounds excellent. Many of the huge SoundFonts are just mish-mashes of several other SoundFonts and may not be well-crafted overall.

TL;DR - don't think about it too much - all supported Pi models have ample RAM for our purposes. 🙂
Hope that helps!

[rhester72]

VERY thorough answer (and pretty cool trivia! ;), thank you!