jack2/TODO

---------------------
  Jackdmp Todo list
---------------------


2008-03-12 : Do not start the client RT thread if no callback or thread routine has been setup (no use of jack_set_process_callback or jack_set_process_thread). This require change in the server to avoid signaling the client in this case. Check direct access from server internal clients (see comment in JackInternalClient::JackInternalClient() in JackInternalClient.cpp)

2008-02-07 : Pipelining idea:

- cut the driver buffer size in n slices : clients see the divided value, server deal with the driver value, some clients may want to keep the driver buffer size (non pipelining)
- new jack_set_buffer_divisor/jack_get_buffer_divisor and jack_set_pipelining/jack_get_pipelining API
- jack_set_buffer_size changes the driver buffer size, jack_get_buffer_size get the divided value
- buffer_size callback notify the divided value for pipelining clients

2008-02-06 : Do a "fork-exec" for the server (deamon..)

2008-02-05 : Hierarchical model : having several client graph running simultaneously (Fons) with a "link" between them (AKA NetJack)

2008-01-15 : Server control API (Nedko Arnoudov): would help to develop external control applications (DBUS or OSC based...)

2007-12-16 : Dynamic backend switch, so that audio backend can be switch off and replaced by the dummy backend.

2007-10-17 : Optimize activation call graph with multiple clients in a same process

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?

2007-10-07 : Before doing an official package, check all public headers

2007-03-14 : Check JackGraphManager::GetPortsAux after MIDI branch merge.

2007-03-14 : Add Paul dynamic jack server location code.

2007-01-22 : Check the "dead" client removing code in the server : non running client may cause Desactivation and Close time out problems.