4 Feb
2008
4 Feb
'08
3:23 p.m.
I'm assuming you meant to post this to the list, Paul.
In reply to your comment:
One of the motives behind jack-dbus is that a JACK control application
shouldn't have to be RT capable since it's not processing any
realtime-sensitive data anyway. From a technical perspective, could
libjack be extended with such a non realtime control API?
-------- Original Message --------
Subject: Re: [LAD] Summercode 2008: LASH, pt. 3
Date: Mon, 04 Feb 2008 11:33:44 -0500
From: Paul Davis <paul(a)linuxaudiosystems.com>
Reply-To: paul(a)linuxaudiosystems.com
Organization: Linux Audio Systems
To: Juuso Alasuutari <juuso.alasuutari(a)gmail.com>
References: <47A4B4DC.8080306(a)gmail.com>
<20080204123036.GJ2670(a)zita2.kokkinizita.net> <47A73ADC.5060207(a)gmail.com>
On Mon, 2008-02-04 at 18:18 +0200, Juuso Alasuutari wrote:
That being said, I still do favor D-Bus over OSC.
The point is that they are both irrelevant in the context of JACK
itself. First you need an API in JACK to control what you want to
control. Then you need a JACK-aware application that speaks <your
preferred protocol>. When it gets <your preferred message> it invokes
the <relevant part> of the JACK API.
4 Feb
4 Feb
5:45 p.m.
On Mon, 2008-02-04 at 22:23 +0200, Juuso Alasuutari wrote:
I'm assuming you meant to post this to the list,
Paul.
In reply to your comment:
One of the motives behind jack-dbus is that a JACK control application
shouldn't have to be RT capable since it's not processing any
realtime-sensitive data anyway. From a technical perspective, could
libjack be extended with such a non realtime control API?
there are many parts of the JACK API that are not RT-bound. in fact,
basically *all* of it except for a clients process() callback, which a
client is not required to register.
6:10 p.m.
Paul Davis wrote:
there are many parts of the JACK API that are not
RT-bound. in fact,
basically *all* of it except for a clients process() callback, which a
client is not required to register.
I guess the "synchronous" response to port appearance/connection
events
(like application connecting ports before next event is generated by
JACK) pretty much requires RT in those applications. Is that right?
Or are those callbacks called in non-audio thread context and don't
block audio? (I suppose they block audio, because I see several watchdog
timeouts which seem to be related to patchbay applications doing screen
updates etc.)
Krzysztof
5 Feb
5 Feb
2:24 a.m.
Le 5 févr. 08 à 00:10, Krzysztof Foltman a écrit :
Paul Davis wrote:
jackdmp used a 2 threads model on client side: one RT thread for
audio (call the "process" callback) and one non RT thread for
"notification" callback (like graph reorder, port register, connect/
disconnect...)
Stéphane
there are many parts of the JACK API that are not
RT-bound. in fact,
basically *all* of it except for a clients process() callback,
which a
client is not required to register.
I guess the "synchronous" response to port appearance/connection
events
(like application connecting ports before next event is generated by
JACK) pretty much requires RT in those applications. Is that right?
Or are those callbacks called in non-audio thread context and don't
block audio? (I suppose they block audio, because I see several
watchdog
timeouts which seem to be related to patchbay applications doing
screen
updates etc.)
Krzysztof
5930
days inactive
5931
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
4 participants
participants (4)
-
Juuso Alasuutari -
Krzysztof Foltman -
Paul Davis -
Stéphane Letz