| Linux DSP/BIOS Bridge release |
| |
| DSP/BIOS Bridge overview |
| ======================== |
| |
| DSP/BIOS Bridge is designed for platforms that contain a GPP and one or more |
| attached DSPs. The GPP is considered the master or "host" processor, and the |
| attached DSPs are processing resources that can be utilized by applications |
| and drivers running on the GPP. |
| |
| The abstraction that DSP/BIOS Bridge supplies, is a direct link between a GPP |
| program and a DSP task. This communication link is partitioned into two |
| types of sub-links: messaging (short, fixed-length packets) and data |
| streaming (multiple, large buffers). Each sub-link operates independently, |
| and features in-order delivery of data, meaning that messages are delivered |
| in the order they were submitted to the message link, and stream buffers are |
| delivered in the order they were submitted to the stream link. |
| |
| In addition, a GPP client can specify what inputs and outputs a DSP task |
| uses. DSP tasks typically use message objects for passing control and status |
| information and stream objects for efficient streaming of real-time data. |
| |
| GPP Software Architecture |
| ========================= |
| |
| A GPP application communicates with its associated DSP task running on the |
| DSP subsystem using the DSP/BIOS Bridge API. For example, a GPP audio |
| application can use the API to pass messages to a DSP task that is managing |
| data flowing from analog-to-digital converters (ADCs) to digital-to-analog |
| converters (DACs). |
| |
| From the perspective of the GPP OS, the DSP is treated as just another |
| peripheral device. Most high level GPP OS typically support a device driver |
| model, whereby applications can safely access and share a hardware peripheral |
| through standard driver interfaces. Therefore, to allow multiple GPP |
| applications to share access to the DSP, the GPP side of DSP/BIOS Bridge |
| implements a device driver for the DSP. |
| |
| Since driver interfaces are not always standard across GPP OS, and to provide |
| some level of interoperability of application code using DSP/BIOS Bridge |
| between GPP OS, DSP/BIOS Bridge provides a standard library of APIs which |
| wrap calls into the device driver. So, rather than calling GPP OS specific |
| driver interfaces, applications (and even other device drivers) can use the |
| standard API library directly. |
| |
| DSP Software Architecture |
| ========================= |
| |
| For DSP/BIOS, DSP/BIOS Bridge adds a device-independent streaming I/O (STRM) |
| interface, a messaging interface (NODE), and a Resource Manager (RM) Server. |
| The RM Server runs as a task of DSP/BIOS and is subservient to commands |
| and queries from the GPP. It executes commands to start and stop DSP signal |
| processing nodes in response to GPP programs making requests through the |
| (GPP-side) API. |
| |
| DSP tasks started by the RM Server are similar to any other DSP task with two |
| important differences: they must follow a specific task model consisting of |
| three C-callable functions (node create, execute, and delete), with specific |
| sets of arguments, and they have a pre-defined task environment established |
| by the RM Server. |
| |
| Tasks started by the RM Server communicate using the STRM and NODE interfaces |
| and act as servers for their corresponding GPP clients, performing signal |
| processing functions as requested by messages sent by their GPP client. |
| Typically, a DSP task moves data from source devices to sink devices using |
| device independent I/O streams, performing application-specific processing |
| and transformations on the data while it is moved. For example, an audio |
| task might perform audio decompression (ADPCM, MPEG, CELP) on data received |
| from a GPP audio driver and then send the decompressed linear samples to a |
| digital-to-analog converter. |