[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[fluid-dev] Jack, FluidSynth, realtime and non-realtime use cases
From: |
David Henningsson |
Subject: |
[fluid-dev] Jack, FluidSynth, realtime and non-realtime use cases |
Date: |
Mon, 31 May 2010 05:40:31 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 |
Hello Jack devs,
FluidSynth has support for both Jack MIDI and Jack audio.
FluidSynth should support both realtime use cases (such as live playing
on a piano) and non-realtime use cases (such as rendering a mixdown). I
assume that Jack also supports both use cases.
Now, there are some midi messages for which FluidSynth can't guarantee
low enough latency, e g program change messages. In the real-time use
case, FluidSynth's best strategy would probably be to internally process
these events asynchronously (i e in a different thread), and queue up
other MIDI events behind to avoid reordering. And in parallel process
audio callbacks (with the old MIDI state) in order to avoid dropouts.
In the non real-time use case however, latency is not an issue, but
predictability is, so we should just process events as they come. And
the strategy outlined above will fail miserably in that use case.
The question then is: How can FluidSynth, via the Jack Client API,
determine if we're in "real-time" or "non real-time" mode, and choose
strategy accordingly?
// David
- [fluid-dev] Jack, FluidSynth, realtime and non-realtime use cases,
David Henningsson <=