fluid-dev
[Top][All Lists]
Advanced

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

[fluid-dev] Timing revisited


From: David Henningsson
Subject: [fluid-dev] Timing revisited
Date: Fri, 10 Apr 2009 15:09:45 +0200
User-agent: Thunderbird 2.0.0.21 (X11/20090318)

What first was a quick fix that took an hour or two to write, expanded
to fix ticket #15, and should also be expanded to fix the sequencer. And
now I'm about to suggest that timing should be a separate
component/subsystem.

First some history (from someone who has only been around the project a
month!). Fluidsynth's was initially designed for live playing only but
it's real strength - and where it is most used - is as a rendering
library, you put midi & sf2 in, you get audio out. The synth component
is working as a rendering library, and with my patches we have a MIDI
player and a file renderer component that also works in the rendering
library context.

As a rendering library, there is almost no use for anything else than
sample timers. But for live, real-time playing usage, there are needs
for synchronization with other things, wall clock, midi clock, and
perhaps other timing sources. Now the existing wall clock timer
implementation (or its interaction with other components) has at least
two serious flaws, 1) it has concurrency problems and 2) it works bad
with large audio period sizes.

To solve the concurrency issue, we must not input MIDI to the synth
during fluid_synth_one_block, only between. A callback from the synth to
the "timing component" before or after fluid_synth_one_block serves two
purposes, 1) it says that now it's ok to input some more MIDI, 2) it
says that the sample timer has advanced. The timing component can then
call registered players/sequencers to tell them to input MIDI.
If this is a rendering library, nothing else is needed. But for
real-time playing, the timing component must resynchronize with the wall
clock (or something else). This can be done rather easily. If the wall
clock has a triggered event every second, we correct the elapsed time
every second, but we use the sample timers inbetween for millisecond
precision.

Assuming you agree that this is a good idea, should such a timing
component be scheduled for 1.1.0 or should it be in the 2.0 branch?

// David




reply via email to

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