Faster than realtime has no sense for the sequencer. It has sense,
though, if
the sequencer is driven by a slave timer, like the one you have
implemented.
This design is already inside (for instance) the ALSA sequencer,
which allows
several timer sources: slave timers linked to the PCM streams, and
wall clock
timers using the RTC, HPET and System devices. There is some
documentation
about that: http://www.alsa-project.org/~frank/alsa-sequencer/node5.html
The user should be able to choose between wall clock and slave
timer, the same
option for the sequencer and the MIDI player.
As stated earlier, we disagree on this. I can see the use for having
other timers than the sample timer (especially after having read about
the ALSA sequencer), but if the wall clock implementation has
concurrency problems, it's broken. To fix that, it would be better to
use the sample timer feature in the synth just to get notification at
the right time, but then try to figure out a better value for the msec
parameter.
My plan is to replace the Windows timer implementation by the
multimedia timer
in that platform, and add the ALSA timers in Linux.
I'm not familiar with ALSA timers; but from what I know of multimedia
timers, that won't solve the "drunk drummer problem". Let's assume for
simplicity that we have a really fast computer, output to file, sample
rate is 44100Hz, and period-size is 4410, that is, 10 periods per
second.
Then the file audio driver will, ten times per second, make 4410/64
= 69
calls to fluid_synth_one_block without any delay inbetween. It does
not
matter how fantastic millisecond precision your timing is in the midi
player/sequencer - you won't be able to insert anything in between the
ten times per second anyway (unless you use the sample timer
notification feature).