[LAD] [Fwd: Re: Summercode 2008: LASH, pt. 3]
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 <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Organization: Linux Audio Systems To: Juuso Alasuutari <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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 . When it gets it invokes the of the JACK API. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: Summercode 2008: LASH, pt. 3]
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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: Summercode 2008: LASH, pt. 3]
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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: Summercode 2008: LASH, pt. 3]
Le 5 févr. 08 à 00:10, Krzysztof Foltman a écrit : > 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 > 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
