AudYoFlo: Behavior: Running the Test Operation on Chains

The connection of components to process data is called a chain. Each chain defines data to flow from a source to a sink with processing nodes to process the flowing in between. Regarding this chain, the coupling between the components involves a certain data format which must match: each output delivered by one component must match the input as received by the other component being connected by a bridge from one to the other.

If the data format does not match, the user shall be informed and a "start" of the chain can not occur. If a chain is ready for processing due to a match in data formats it may be not ready any longer if, e.g., the number of channels changes in the output sink. However, it may well be possible that the chain might start anyway since one of the components may be able to deal with different settings. Therefore, at anytime before processing, in the phase where all involed components are "ready", a test function propagates the current data formats through all chain elements (components)and finally yield the result of the test: either, all bridges in he processing chain are ready for processing (which is when the start button may be pressed OR there is a connection problem which must be indicated to the user.

Often, a test must be run whenever a parameter is modified. E.g., if the algorithm requires additional channels, the audio source should deliver more channels. In this case, setting the property in the algorithm triggers a new test run as shown in the following Figure.

The process acts as follows:

1. A property is set by the user and enters the component via the set_property function which is exposed by the IjvxProperties interface.
2. The node requests a test by using the IjvxReportSystem interface. It emits an object of type CjvxReportCommandRequest_uid towards the host. The emitted object must be initialized to hold the process id as request load parameter.
3. The host accepts the object and looks the process id up. The corresponding connection process is then triggered to run a test operation on the chain which is invoked by calling the IjvxConnectionMaster interface, function test_chain.

An exemplary call sequence to trigger a test run is implemented in class CjvxNodeBase1io:

jvxErrorType 
CjvxNodeBase1io::inform_chain_test(jvxBool oldMethod) 
{ 
	jvxErrorType res = JVX_NO_ERROR; 
	jvxSize processId = JVX_SIZE_UNSELECTED; 
	IjvxDataConnectionCommon* dataConn = NULL;`

	// Inform the secondary chain to be updated
	associated_common_icon(&dataConn);
	if (dataConn)
	{
		dataConn->unique_id_connections(&processId);
	}
	if (JVX_CHECK_SIZE_SELECTED(processId))
	{
		res = this->_request_command(
			CjvxReportCommandRequest_uid(
				jvxReportCommandRequest::JVX_REPORT_COMMAND_REQUEST_TEST_CHAIN,
				_common_set.theComponentType, processId));
	}	
	return res;
}

Typically, a test run does not happen immediately as soon as the set_property function is called. Instead, it is delayed to allow the set_property function to complete before the full chain is processed. The emit of the object to the host therefore has no immediate reaction. Instead the request is stored in a trigger list.

In the figure, the request to run the test is stored in a queue in the host and in particular the global IjvxDataConnectons instance by calling the member function

jvxErrorType add_process_test(jvxSize uIdProcess, jvxSize* numTested, jvxBool immediatetest);

This function may run the test in a delayed way or - alternatively - immediately, The caller can force the test run to occur immediately when setting the third argument to true. If the test is run, the argument numTested contains the number of tests run during the call to determine any possible system changed. While the function to add a test request can be called from any thread, the immediate test request should only occur from within the main thread.

The purpose to postpone the test function is indeed part of the responsibility of the host application since each frontend may have different mechanisms for async triggering of specific functions. Note that, typically, the IjvxReportSystem interface is provided by the UI app framework which involves the AudYoFlo host functionality.

If a simple property is set, the described process is straight forward. However, often new triggers of the test run are required during the test run of another chain. If a trigger to emit a test request is detected by the host while a test run is currently active the new request is stored by means of the add_process_test function. However, in this case, the requested test run will be run immediately after the current test run has been completed. The test loop is part of the IjvxdataConnections interface and should be invoked by calling the member function

jvxErrorType IjvxdataConnections::trigger_process_test_all(jvxSize* numTested);

If called for one chain test request in the beginning, new trigger requests may be invoked by calling add_process_test from any of the involved components to be stored in the queue. The additional requests will execute if the previous test is complete until there is no test request left.

Note that if test requests are collected during a test run, mutiple pending entries will be cancelled out. This limits the number of test runs and also reduces the risk of endless loops on test. Nevertheless, endless loops may be created by this dependency if chains are mutually dependent.

Back