This section provides general guidelines that authors of LADCCA clients should try to follow in order to get the best out of the LADCCA environment.
It is important that control of a program's ALSA and JACK port connections be submitted to LADCCA in order for its actions to be meaningful. For example, a client which on startup connects its output ports to the hardware will wreak havoc if the user reconnects the outputs to different ports and LADCCA later restores the client. The ports will be connected to both the hardware and the user-specified ports.
It is also tempting to save the destination to which output ports are connected. This is not only redundant, but could be problematic. If, for example, a client is connected to two instances of another client and saves those destinations, the destinations may have switched when the clients are restored. This is a particular danger with ALSA clients where the client and port identifiers are numerical and assigned by the sequencer system.
Generally speaking, a client should at no time venture beyond the boundary of its own ports unless explicitly requested by the user (by way of the command line or a GUI configuration option.) If a client is required to, such functionality should always be disabled if LADCCA is active.
The frequency at which a client should check for, and respond to LADCCA events is not critical. It should be considered similarly to user interface events; 10 seconds is too long to wait, 1 second is acceptable, 0.1 seconds is good. Most GUI toolkits provide an idle callback facility; this is an ideal place for the event loop. If the program is bound to terminal input then the event loop should not be within the main control loop; waiting for user input to deal with LADCCA events is unacceptable. A seperate thread for the LADCCA event loop should be created in this kind of situation.
Go to the first, previous, next, last section, table of contents.