clients, ports, connections

[Fons Adriaensen-2]

Hello all,

There are at least 2 serious problems with the current
API used by clients such as qjackctl to monitor clients,
ports and connections.

The first can be best explained by some abstract example.
Suppose there is some value X in jackd that a client
wants to be informed of. There are two ways to get it:
- a function get_X() to read the current value,
- a callback X_callb() called whenever X changes.

Now if a client first enables the callback and then
uses get_X() it could end up with two different values
and no way to find out which one is the more recent
(because the call to get_X() and the callback happen
in different threads).

If the client first calls get_X() and then enables
the callback it could have missed a callback that
changed the value it obtained from get_X().

The only clean solution to this is to remove (or not
use) get_X(), and make the server immediately issue a
callback when this is enabled. This was discussed some
years ago for the sample_rate value, and jack1 does
indeed operate in that way (and jack2 SVN does since
last week - this was the problem with alsaplayer wich
does the right thing and only uses the callback).

The same situation exist w.r.t. monitoring clients,
ports and connections.

A new client can use jack_get_ports() and jack_port_
get_all_connections() to build up a picture of the
initial situation, and then rely on the client, port,
and connection callbacks to be updated when anything
changes. But here we have the same problem as in the
example above, and also some new ones:

- What will jack_get_ports() return if during the time
  it takes to build the return value (which can be quite
  big), some ports are created or deleted ?

- It takes some time for the client to process all this
  data, and to perform the jack_port_get_all_connections()
  calls. Until this work is finished the client is not
  in a position to accept the callbacks, as they may
  refer to objects that have not yet been created in
  the client's data structures. So a client would be
  forced to store all the data provided by the callbacks,
  to be used after it has finished creating its internal
  data structures, and this is a PITA. And given the
  original problem outlined above, even this would not
  ensure it gets the complete and correct picture.

The second problem is the result of using at least three
data types to represent a port : port_id, port_ptr, and
port_name.

The following mappings are provided:

  id   ->  ptr
  ptr  ->  name
  name ->  ptr  
 
There is no way to obtain an id given a ptr, and
the mapping name -> ptr probably involves a linear
search and is therefore inefficient when used in
(maybe even nested) loops, such as processing the
output from jack_get_ports(), or inside a callback
(which in jack1 occurs in the same thread as the
process callback, and hence blocks audio processing).

The result is that the client is forced (*) to build
its internal data structure either in terms of names
(creating duplicates of data in an inefficient format)
or pointers (dangerous, and meaningless except locally).
For clients, only the names exists.

...

Combining the conclusions from the two points above,
a clean API could work as follows:

1. A new application connects to the server.
   It finds out the values of
   - max_client_id
   - max_port_id
   and uses these to create its data structures.

2. The application enables the client_callback.
   As a result it gets a number of 'new client'
   callbacks, processed by the normal code for this
   callback. Clients are identified by client_id,
   the name can be found by get_client_name(client_id).

3. The application enables the port_callback.
   As a result it gets a number of 'new port'
   callbacks, processed by the normal code for this
   callback. Ports are identified by (client_id,
   port_id). The short (excluding client name) name
   can be found by get_port_name(port_id).

4. The application enables the connection_callback.
   As a result it get a number of 'connect'
   callbacks, processed by the normal code for this
   callback. Connections are identified by (client_id,
   port_id, client_id, port_id) the first pair being
   an readable port and the second a writeable one.

5. The client continues processing client, port, and
   connection callbacks.

(1) Unless it uses dirty tricks to find the port_ids,
which could break with any new release.


Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org