XDAIS FAQ

Where can I download XDAIS?

The latest XDAIS releases are available here.

What happened to the ALG libraries?

The ALG libraries were removed from XDAIS in the 5.00 release in 2006. System integrators are recommended to use the Codec Engine framework, or DSKT2, provided in Framework Components, if a lower-level interface is needed.

Can algorithm providers name interface structures like <VENDOR><MOD>_Params?

• Q: XDAIS seems to recommend naming interface structures like <MOD>_Params without vendor name whereas we name them like <VENDOR><MOD>_Params to highlight vendor name. Is this deviation acceptable as far as XDAIS compliance is concerned? We have noticed that including vendor name helps application developer differentiate same Algo from different developers.
• A: No. The reason is that most consumers want to realize the true value of plug and play. When XDAIS was first introduced in 1999 one of the linker statements integrating sample algorithms was: -

/* 
 *  Algorithm FIR: bind the generic FIR symbol to TI's implementation
 *  of the algorithm, and include the appropriate library
 */
-l fir_ti.l64
_FIR_IFIR = _FIR_TI_IFIR;

The rationale for this was to ensure clients could have vendor-agnostic code. Some customers integrate algorithms from 6 or 7 different vendors hence the application code needs to be insulated from this detail.

For this reason, we should not have <VENDOR><MOD>_Params, because this is an exposed entry point to the application.

Can algorithm providers name IALG fxn tables like <MOD>_<VENDOR>_FXNS?

• Q: XDAIS recommends module function table name like <MOD>_<VENDOR>_<IMOD> whereas we name them like <MOD>_<VENDOR>_FXNS. Is this deviation acceptable? In the same context what about <VENDOR>_<MOD>_FXNS naming where vendor name precedes module name? The logic here is that the way "ialg" points to an IALG function table like <MOD>_<VENDOR>_IALG similary “fxns” field in should point to a function table named like <MOD>_<VENDOR>_FXNS. This also matches with the naming convention of default initialization parameters <MOD>_PARAMS (where the name of corresponding structure type is <MOD>_Params.
• A: Again unfortunately not. Tooling needs to depend on some conventions. The above convention is Ok but it's different. Its too difficult to have tooling understand multiple styles. QualiTI for example looks for <MOD>_<VENDOR>_<IMOD>. Codec Engine in turn needs this symbol to know the IALG and processing XDM entry point for an algorithm.

Are algorithm providers required to provide a <MOD>_<VENDOR>.h file?

• Q: Is it mandatory for algorithm developer to make MOD_VENDOR.h file available for application integrator? Most of the time both iMOD.h and MOD_VENDOR.h header files are required for app integration. Can these two files be combined or in other words can the function declarations in MOD_VENDOR.h be moved to iMOD.h file?
• A: We don't want to combine iMOD.h and MOD_VENDOR.h - the former is used to specify the interface for any vendor's usage of that interface. The latter is there to e.g. expose extension entry points for a particular vendor implementation.

Often you don't need the MOD_VENDOR.h file - i.e. most algorithms try to stick with the base interface so that it can be used in any framework without customization.

Make this file available if you really do extend the algorithm and have required APIs that need called in addition to the XDAIS/XDM/VISA standards.