-
-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🐛 [BUG] Soundfont - SF2 file > 1gb will fail to load #327
Comments
Thank you for the detailed bug report and providing the logs, it's much appreciated. The reason for this is because of the way Circle's memory map/allocation is implemented. Unfortunately, we don't get access to the whole 4GB (or 8GB on those models) at the moment. On Pi 4, the first 1GB is called the "low heap", and Circle's internal memory allocator uses this. The next 2GB is the "high heap" and is handled by mt32-pi's custom allocator - this is what FluidSynth uses. The remaining 1GB on Pi 4/4GB (or 5GB on Pi4/8GB) is not usable right now. That said, we are only getting 940MB of "high heap" according to your log, when it should be closer to 2GB, so this needs investigating. (On Pi 2/3/02W there is no "high heap", only a "low heap". Here, 32MB is reserved for Circle's internal allocator, and the remainder is handled by ours). Circle's internal memory allocator cannot keep track of large allocations, hence the need for a custom allocator, otherwise FluidSynth cannot unload SoundFonts and free the memory for when the user wants to load another one. There are a few things that need to happen so that we can use the rest of the memory on Pi 4:
I will need some time to figure out the best way to solve this. P.S. thank you very much for the donation, I really appreciate it! 🙂 |
Hello and thank you very much for the detailled answer, your project is really great, and useful for a lot of people including me.
I would first try to set a fixed value for "nHighHeapSize" and see what happens, but I'm unfortunately not able to fork your code, I'm a C# dev. with no experience with C++ |
I read the memory.h Circle code, and this may explain things : In case of Pi4, Your custom allocator does the following : According to Circle, using HEAP_ANY should also add the HEAP_LOW Free Space and return an addition of both, even if it's not clear why the HEAP_HIGH zone only returns 940mb. I now have to figure out how I can compile your code :D |
It's not that simple. The custom allocator needs to make one large, single contiguous allocation from either one of those heaps, so using the size of "any" (the two heap sizes added together) doesn't make sense. Changing the The best solution (which I have wanted to do for a long time due to other related issues) will be to remove Circle's allocator completely and use the Zone allocator system-wide. There is a branch ( |
Interesting ! I'll look into that branch and see what I can find. Thank you :) |
I was able to compile the code and made a slight change :
HEAP_HIGH part of the code dedicated to RPI4 was always ignored. I believe because of the RASPI variable that is never initialized in the compilation process. My change :
As you explained to me, the HIGH_HEAP zone was able to allocate 2048mb :) |
Hardware and software
Bug description
Any attempt to load SF2 files bigger than 1gb will fail. "SF switch error".
Steps to reproduce
Expected behavior
File should load successfully : 3488 samples, 59231 instrument generators, 1611 preset generators
Configuration file
Click to expand
Videos/audio recordings
Nothing
Additional information
I can provide the SF2 file if needed.
The text was updated successfully, but these errors were encountered: