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@email-addr-hidden>
Reply-To: paul@email-addr-hidden
Organization: Linux Audio Systems
To: Juuso Alasuutari <juuso.alasuutari@email-addr-hidden>
References: <47A4B4DC.8080306@gmail.com>
<20080204123036.GJ2670@email-addr-hidden> <47A73ADC.5060207@email-addr-hidden>
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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Feb 5 00:15:03 2008
This archive was generated by hypermail 2.1.8 : Tue Feb 05 2008 - 00:15:03 EET