Programmer Guide/SPU Reference

Signal processing units (SPU) provide the STx programmer with the possibility to create their own signal processing algorithms. Using a set of predefined atoms, the programmer can develop such things as a ...

• synthesis circuit (e.g. additive synthesis using the ADDSYN atom)
• real-time spectrum analyzer (using SPECTRUM and WAVEIN atoms)
• complete speech analysis (e.g. by using the atoms F0SIFT, RMS and LPCOEFS)
• ...

The SPU subsystem consists of the build-in Signal Processing Atoms (SP-atom), the SPU ciruit defintion languange and the SPU shell items, implementing the run-time instances of the signal processing circuits. SPU are defined using the circuit definition language. Once defined, they can be instantiated in an SPU item, or used as an element in another SPU.

Advantages

• fast signal processing: SP-atoms are C++ classes using special math libraries for acceleration
• parallel processing: each SPU instance may run in its own thread
• fast data exchange: data exchange using direct access (between SP atoms) and messages (between SP atoms and other shell items - e.g. graphs)
• complex circuits: SPU instances can be interconnected to build complex processing circuits
• flexibility:
• real time signal processing is possible

An alternative for implementing signal processing algorithms is the EVAL command. The EVAL command makes the algorithms more readable and also more flexible, because the whole scripting language can be used for the implementation, but the execution is slower and needs more memory. In many cases a combination of SPUs (with or without their own threads) and EVAL will be the optimum choice for the implementation.

The picture shows a simplified block diagram of an SPU item and its connections to other shell items

SPU Instantiation

The SPU source code defines a type of circuit. An SPU shell item is an executable instance of a circuit and is created from the source code using the NEW SPU command. On creation, the following steps are taken:

• An instance is created for all local elements. If an element is itself an SPUnit, it is replaced with the internal circuitry of this SPUnit and then its local elements are instantiated. This process is continued until all SPUnit have been replaced with their most basic elements (SPUnit). The interconnection, as defined in the function statements, is carried out at the same time as the instantiation.

• The second step initializes all the SPAtoms. All constant arguments are evaluated and used as initialization parameters for the SPAtoms. Additionally, all connections are tested (i.e. are all the necessary inputs available? Are all the data types compatible and valid?).

On completion of this compilation procedure, the SPUnit item is ready for use. A new process is started which is responsible for the control and execution of the item. On creation of an item, all initializations (parameters) and connections (inputs) are carried out. The data types and the sizes of the outputs are fixed. The outputs are, however, not connected!

The SPU outputs can be connected to the inputs of another SPU, to the inputs of a graph or to a value item. The output connection occurs after creation by the relevant macro commands. This has to happen before the beginning of the processing. An active (running) SPU item's connections cannot be changed (created or destroyed).

Because SPUs run in separate threads, a message handler has to be installed before the SPU is started. The most important message sent by an SPU is the STOP message. This message indicates that the processing (and therefore the data exchange with other items) has finished.

Signal Processing Atoms

All build-in SP-atoms in alphabetical order:

Notes:

• If an input is marked as variable, its value can be changed in every evaluation cycle.
• If an input is marked as constant, its value is only used during the initialisation.
• The datatype and the dimensions of an input (also if marked as variable) are checked during the initialisation and can not be changed.
• If an output is marked as variable, its value is changed in every evaluation cycle.
• If an output is marked as constant, its value is assigned during the initialisation and not changed during the execution.
• The datatype and the dimensions of an output (also if marked as variable) are set during the initialisation and not changed during the execution.

<splist parent= sort=asc sortby=title showpath=no liststyle=bar kidsonly=yes >