[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[fluid-dev] Exploring the lower limits of FluidSynth.

From: Carlo Bramini
Subject: [fluid-dev] Exploring the lower limits of FluidSynth.
Date: Sun, 18 Nov 2018 20:30:24 +0100 (CET)

I would like to share some experiences when working on FluidSynth on different platforms.

Embedded platform with ARM Cortex M3.

This is an embedded platform with these features:
- ARM Cortex M3 (NXP LPC1788), 120MHz, NO FPU, no caches.
- 512KB of internal flash.
- 8MB of SDRAM clocked at 60MHz.
- 8MB of NOR parallel flash.

I compiled FluidSynth with these options:
- I added a function for rendering 8bit samples.
- manually set FLUID_INTERP_DEFAULT=FLUID_INTERP_NONE into synth.h

Results: well, although it works, this is not exacly a success. I disabled reverb, chorus and I set up the mixing frequency to 11025Hz. I'm getting an half second of sound every 3 or 4 seconds when playing "Fluorish.mid" file. When playing samples from the keyboard, I can get 2 or 3 notes of well played poliphony. More notes at the same time will break the sound. Sad experience...

Windows Embedded/CE/Mobile, ARMv5 CPU

I have two PocketPCs, an Asus A620 and a Dell x50v.
These devices are based on Intel XScale PXA255 (400MHz) and PXA270 (624MHz).
They are probably the fastest legacy ARM platforms available WITHOUT an hardware FPU.
Since these versions of Windows do not support DirectSound, I implemented an output driver for supporting WaveOut APIs. I will provide more information on this topic soon.

Again, I compiled with WITH_FLOAT=1 and FLUID_INTERP_DEFAULT=FLUID_INTERP_NONE. Reverb and chorus are disabled and the mixing frequency is 11025Hz.

Results: knowing the horsepower of these devices, I admit that I expected better results. More or less, both devices play MIDI files sloooowww, like if it is working at half of the speed or even less. Sad experience again...

Intel Pentium 200MHz MMX

I keep this machine as a relic because it is my first PC.

Results: incredibly, it worked. Obviously, I disabled chorus and reverb and I lowered the mixing frequency to 22050. MIDI files are played quite well, although you can listen some slowdowns when there are many voices playing. Recompiling FluidSynth with WITH_FLOAT=1 changed greatly the playback performance, I can say 50% faster. The CPU usage in the task manager runs between 20% to 80%, without reaching the saturation anymore. Evidently, FPU is hardware and powerful and it is able to handle "double" and "float" types almost at the same speed, but since FluidSynth moves big amounts of memory, then switching from 8-bytes to 4-bytes floating point removed the bottleneck of the 32bit bus of the processor when handling "double" types.

One thing is quite funny: when closing the test program, the function delete_fluid_midi_event(), which is called by delete_fluid_track(), required from THREE to FIVE MINUTES to be completed. I was thinking that the PC was locked, but after attaching the debugger I discovered that it was just doing TONS of calls to free(). Urgh!!!!

At the time of writing, it seems to me that the MINIMUM requirements for running FluidSynth are:

1) hardware FPU. You cannot play anything without it. In my second test, the ARMv5 processors are more powerful than my old 200MHz PC, but the FPU made the big difference.

2) I think that a 500Hz CPU should be enough for getting a decent experience, if you won't exagerate with the options.

3) RAM width and RAM speed: on 32bit systems, the WITH_FLOAT=1 option is still helpful even if you have an FPU.

4) Make sure that you have enough RAM space: my ARM Cortex M3 has 8MB of RAM, but when loading a 2MByte SF2, I got an "Out of Memory". It seems strange, but it happened to me.

Epilogue: I hope you will find these tests interesting.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]