Hello again,
I'm still triying to understand and potentially try to find a
solution for the mentioned problem.
One lead that I have is that both problems actually come from the
fact that there are two clocks : the audio clock determined by the
samples computed by the synth and sent to the sound driver (in the
fluid_synth_one_block function), and the realtime clock that is used
by the sequencer. So maybe a simple solution to both problems would
be to trigger the sequencer not using a system timer (which is the
real time), but rather with the audio clock, i.e. from calls from the
fluid_synth_one_block function. This way, we would have two benefits:
- the time precision would be the size of the fluid_synth_one_block
buffer (64 frames by default, i.e. 1.5ms)
- the sequencer clock would be the same as the audio time
I don't see any other problem than overloading the audio thread,
which would need to process the sequencer commands (noteon, etc...).
Would this be overkill ?
Does that seem like a clean and simple route ?
Any advice or opinion appreciated (the silence on this topic is a bit
unusual, does it mean that nobody has a clue ? Or am I not clear ?).
Thanks a lot,
Le 12 juin 07 à 12:45, Antoine Schmitt a écrit :
Hello all,
any ideas on these two issues ? Confirmation ? Fix ? Workarounds ?
Remainder :
- intrinsic inaccuracy of fluid because of underlying driver bursts
requests of 512 frames.
- timer on Windows not always 1ms apart (because of the audio
thread priority ?)
Thanks a lot for any help,
Le 7 juin 07 à 11:05, Antoine Schmitt a écrit :
I'd be very grateful if someone could confirm my analysis,
especially on the problem with the bursts and its consequences on
inaccuracy. And maybe think of ways to fix this.
++ as
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
++ as
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
