[Top][All Lists]

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

[fluid-dev] Multi core support committed and improved

From: josh
Subject: [fluid-dev] Multi core support committed and improved
Date: Tue, 29 Sep 2009 15:48:45 -0700
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

After implementing a mostly lock-less version of the multi-core support and optimizing it nicely (locks are only held for thread synchronization, which occurs once per fluid_synth_one_block), I went ahead and committed my changes. Basically all the voices are synthesized to their own dedicated audio buffers, which turns out to be not all that much data (FLUID_BUFSIZE * 256 for polyphony=256 is 64K for 32 bit float data) and simplified the logic greatly (no need to handle buffer starvation). Once all voices have been synthesized, the primary synthesis thread mixes them all to the left/right/chorus/reverb buffers. At this point, I think the overhead is pretty minimal. I ran up to 8 cores on my single core laptop and saw fairly small overall CPU increase compared to single core. So I'm much happier with this now.

I tested it on my little brother's core duo laptop and saw -F fast rendering increases of anywhere from 11-25%. A decrease of 25% in render time doesn't seem all that bad, if you consider that the maximum theoretical reduction of 2 CPUs would be 50%. I imagine some of the other code paths (reverb/chorus, etc) are probably rather significant and could perhaps also benefit from multi-cores (perhaps do reverb and chorus separately or something).

I also added audio.realtime=yes/no, midi.realtime=yes/no, audio.realtime-prio=1-99 and midi.realtime-prio=1-99 as I discussed before. The core threads take advantage of this, to try and be the same priority as the audio threads. The possible priority inconsistency is still an issue for programs embedding FluidSynth though, but it would still work, just perhaps not optimally.

A couple of bug fixes got committed too, which I caught with valgrind. The -F fast render option is really useful for benchmarking and debugging. Thanks for adding this! :)

I'd like to hear of other user's experiences with the new multi core support, on multi-core machines (a quad core or higher would be nice to get results on). In summary, its useful if you want to maximize the number of potential FluidSynth voices on your system or -F fast render quicker to an audio file. The largest benefit is seen when there are a lot of voices in a MIDI composition or sequence. To try it, just pass -o synth.cpu-cores=N, where N is something like 2, 4, 8 or 256 ;)



reply via email to

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