Jack, FluidSynth, realtime and non-realtime use cases

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Jack, FluidSynth, realtime and non-realtime use cases

David Henningsson
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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack, FluidSynth, realtime and non-realtime use cases

Stéphane Letz

Le 31 mai 2010 à 05:40, David Henningsson a écrit :

> 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

Using "jack_is_realtime"  ?

http://jackaudio.org/files/docs/html/jack_8h.html#ab6d7b40dc5865b8011436b6853fa090f

Stéphane


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack, FluidSynth, realtime and non-realtime use cases

David Henningsson
On 2010-05-31 08:24, Stéphane Letz wrote:

>
> Le 31 mai 2010 à 05:40, David Henningsson a écrit :
>
>> 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
>
> Using "jack_is_realtime"  ?
>
> http://jackaudio.org/files/docs/html/jack_8h.html#ab6d7b40dc5865b8011436b6853fa090f

Sorry if the terms are confusing. Let me rephrase: I'm assuming that
JACK has a faster-than-realtime mode, for performing mixdowns as fast as
the computer can handle. Is that correct? If so, how do I know if we're
currently in such a mode?

(If the answer is still "Jack_is_realtime", the documentation is wrong.)

// David


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack, FluidSynth, realtime and non-realtime use cases

Stéphane Letz

Le 31 mai 2010 à 12:34, David Henningsson a écrit :

> On 2010-05-31 08:24, Stéphane Letz wrote:
>>
>> Le 31 mai 2010 à 05:40, David Henningsson a écrit :
>>
>>> 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
>>
>> Using "jack_is_realtime"  ?
>>
>> http://jackaudio.org/files/docs/html/jack_8h.html#ab6d7b40dc5865b8011436b6853fa090f
>
> Sorry if the terms are confusing. Let me rephrase: I'm assuming that
> JACK has a faster-than-realtime mode, for performing mixdowns as fast as
> the computer can handle. Is that correct? If so, how do I know if we're
> currently in such a mode?
>
> (If the answer is still "Jack_is_realtime", the documentation is wrong.)
>
> // David
>
>

Sorry, use the freewheel callback for that :

http://jackaudio.org/files/docs/html/group__ClientCallbacks.html#gac8e87f2c4054afc41c98c8f6a2460859

Stéphane
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack, FluidSynth, realtime and non-realtime use cases

David Henningsson
On 2010-05-31 12:42, Stéphane Letz wrote:

>
> Le 31 mai 2010 à 12:34, David Henningsson a écrit :
>>
>> Sorry if the terms are confusing. Let me rephrase: I'm assuming that
>> JACK has a faster-than-realtime mode, for performing mixdowns as fast as
>> the computer can handle. Is that correct? If so, how do I know if we're
>> currently in such a mode?
>>
>> (If the answer is still "Jack_is_realtime", the documentation is wrong.)
>>
> Sorry, use the freewheel callback for that :
>
> http://jackaudio.org/files/docs/html/group__ClientCallbacks.html#gac8e87f2c4054afc41c98c8f6a2460859

Thanks, so "freewheel" was the right term. How do I determine the
current mode at startup? Is there also a jack_is_freewheel function
(which I was looking for but didn't find), or should I just assume that
I'm not in a freewheeling mode when connecting to jack initially?

// David
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack, FluidSynth, realtime and non-realtime use cases

Paul Davis


On Mon, May 31, 2010 at 7:02 AM, David Henningsson <[hidden email]> wrote:

Thanks, so "freewheel" was the right term. How do I determine the
current mode at startup? Is there also a jack_is_freewheel function
(which I was looking for but didn't find), or should I just assume that
I'm not in a freewheeling mode when connecting to jack initially?

JACK should not accept new clients while in freewheel mode. You can assume you are not in freewheel mode. This is not an absolute guarantee, but its corner case that I don't think it worth worrying about too much. There cannot be a jack_is_freewheel() function that doesn't suffer from a race condition.

--p


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack, FluidSynth, realtime and non-realtime use cases

Fons Adriaensen-2
On Mon, May 31, 2010 at 08:49:24AM -0400, Paul Davis wrote:

> JACK should not accept new clients while in freewheel mode. You can assume
> you are not in freewheel mode. This is not an absolute guarantee, but its
> corner case that I don't think it worth worrying about too much. There
> cannot be a jack_is_freewheel() function that doesn't suffer from a race
> condition.

Classic problem. Either call the callback as soon as it
is declared, or add a call enabling the user to request
a callback.

Ciao,

--
FA

O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org