Jack client graph activation optimization

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

Jack client graph activation optimization

Stéphane Letz
Hi,

Andrzej Szombierski  recently did interesting test to measure jack  
client activation speed in different context: jack client opened in  
separated processes, multiple jack clients running in the server,  
multiple jack clients running in a same separated process, this using  
jackd or jackdmp.

jackd:

- multiple jack clients in the server: fast because *direct function  
call* to the client process callback is done bypassing the fifo based  
activation system
- jack clients in separated processes: slower using the fifo based  
activation system
- multiple jack clients in a separated process: slower using the fifo  
based activation system

jackdmp:

- multiple jack clients in the server: slower using the fifo based  
activation system
- jack clients in separated processes: slower using the fifo based  
activation system
- multiple jack clients in a separated process: slower using the fifo  
based activation system

So basically jackdmp use the same fifo based activated system in all  
cases, and jackd does some optimization in the "multiple jack clients  
in the server" case.

Also having multiple clients in a same process (jack server or  
separated process) is not so common, it may still be interesting to  
be able to optimize the activation path with sequential clients in a  
same process (server or separated). I am thinking in a method that  
could be done in jackdmp data-flow model: since the activation path  
is "computed on the fly" when following links between clients, the  
step where a client activates all its output could be reworked a  
little with something like:

- find one of the client in the output client list that is in the  
same process
- activate all other output clients using the normal fifo based system
- *direct* call the client process callback

(and this would be done recursively following a sequential path in  
the graph until no more client in the same process is found)

There is still an issue if a client uses the "Fons special" ((-:  new  
jack_thread_wait API, where a client explicitly gives control back to  
libjack... I still don't have a clear idea if this optimization path  
could still be done.

Even if the "multiple clients" way is not really used in existing  
applications, is it a desirable feature to have at some point?

Stephane
 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack client graph activation optimization

Jack O'Quin
On 10/17/07, Stéphane Letz <[hidden email]> wrote:

> Even if the "multiple clients" way is not really used in existing
> applications, is it a desirable feature to have at some point?

Seems useful to me.  JACK should support it.

But, I think it is premature to spend much effort optimizing
for that case until it has proven its usefulness.  Any genuine
performance issues will be much more apparent, then.
--
 joq

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack client graph activation optimization

lars.luthman (Bugzilla)
In reply to this post by Stéphane Letz
On Wed, 2007-10-17 at 15:33 +0200, Stéphane Letz wrote:
> Even if the "multiple clients" way is not really used in existing  
> applications, is it a desirable feature to have at some point?

Obvious use case: MIDI sequencer + recorder program. If the sequencer
and recorder are in separate clients you can send MIDI to an external
softsynth and record its audio output without adding a period of
latency. And when you're using that program without any external
softsynths that in-process optimisation would be nice.


--ll

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jack client graph activation optimization

Stéphane Letz
In reply to this post by Jack O'Quin

Le 17 oct. 07 à 15:41, Jack O'Quin a écrit :

> On 10/17/07, Stéphane Letz <[hidden email]> wrote:
>
>> Even if the "multiple clients" way is not really used in existing
>> applications, is it a desirable feature to have at some point?
>
> Seems useful to me.  JACK should support it.
>
> But, I think it is premature to spend much effort optimizing
> for that case until it has proven its usefulness.  Any genuine
> performance issues will be much more apparent, then.
> --  
>  joq


Well I did most of the needed implementation in jackdmp and the  
results are, for 10 metro like jack client running in a same process,  
on a 4 CPU OSX machine, at 64 frames:

- all in parallel : thus fifo based client activation: jack CPU load  
= 9%
- all in serie : thus "direct call" optimization : jack CPU load = 4.5%

Not so bad!

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel