Audio Soc example

Content is no longer maintained and is being kept for reference only!

Introduction

The audio Soc example is a demo application that illustrates the use of DSP-side peripheral drivers running in conjunction with a Linux kernel application on a ARM processor for select Texas Instruments Soc (System on a Chip) devices. This example contains both a DSP-side and an ARM-side application. The example application uses a DSP-side output audio driver application in-conjunction with an ARM-side application to pass (via a file) raw Pulse-code Modulation (PCM) data to the DSP for processing using Texas Instruments DSP/BIOS Link software stack.

Note: This example is not intended to solve system issues when running peripheral drivers on SOC devices (ARM + DSP cores) but as a starting point for developing applications to take advantage of peripheral drivers on both cores.

When to use and when not to use Codec Engine

This application uses DSP Link - it does not use Codec Engine. The main reasons for this are: -

• DSP-side drivers - the Remote Procedure call invocation mechanism via Codec Engine is not required here.
• minimal system - this application is not intended to be the start point for systems with many XDAIS/XDM algorithms. Rather it is useful for custom apps where the user is adding their own DSP processing and not planning on adding off-the-shelf video, imaging, audio, speech algorithms.
• Low latency - by virtue of using DSP/BIOS deterministic drivers we can achieve lower latencies.

To ascertain whether or not it makes sense to use Codec Engine in your system check out When to use and when not to use Codec Engine.

Application Data Flow

Overview

The ARM-side application uses DSP/BIOS Link's PROC module (to load and run DSP application), POOL module (to allocate contiguous memory in a shared region), and MSGQ module (to pass data buffers to the DSP).

The DSP-side application uses the DSP/BIOS Platform Support Package (DSP/BIOS PSP) drivers in conjunction with the DSP EDMA3 Low Level Driver (EDMA3 LLD) to configure the DSP to process audio sample output which is being inputted by the GPP application. The DSP has three DSP/BIOS tasks (input, process and output) to handle the incoming data, process and output it. The DSP/BIOS MSGQ (Message Queue) module is used to synchronize, pass and process the incoming data in the different tasks (TSKs).

ARM

The ARM-side application is used to load and run the DSP application with the DSP/BIOS Link PROC module. Once the DSP application is running, the application waits for a message (MSGQ) from the DSP. A file (raw PCM data) is then read in and placed in a data buffer. The pointer to the buffer is then passed along to the DSP using DSP/BIOS Link's MSGQ queue module. When the entire PCM data file has been streamed and passed to the DSP, the DSP application is halted and the ARM application is terminated.

The buffers with PCM data used to pass along to the DSP application is allocated using the DSP/BIOS Link POOL module. The buffer is located in a shared memory region allowing both the ARM and DSP core to access it.

DSP

The DSP-side application has three main tasks (input, process and output) that handle the data buffers being inputted from the ARM-side application. At start-up the audio driver is configured (McAsp & I2C), DSP/BIOS Link is initialized, and three MSGQ objects are created, one for each of the corresponding main tasks (TSK). An initialization TSK is started to create a DSP/BIOS SIO stream for the audio driver and all remaining tasks are started.

The input task, sends a message (MSGQ) to the ARM and spins waiting for messages with data from the ARM application. Once a message is received, the data buffer is invalidated to ensure cache coherency and placed on a message queue for the process task to handle.

The process task receives the message with the data buffer. It then performs any necessary algorithm processing (memcpy) on the data buffer and places the buffer on the output tasks message queue.

The output task receives the message with the data buffer and sends the buffer to a stream (SIO_issue) for the audio driver to process. An empty buffer requested from the stream (SIO_reclaim) is passed back to the process task to fill with new data.

The process task sends back a message to the input task which then sends a message back to the ARM for the process of the next PCM data buffer to begin.

Software

The software example described can be found as part of the installation for your Soc (e.g. OMAP-L138) devices SDK package, if supported.

It can also be downloaded as a stand-alone package from:

http://software-dl.ti.com/dsps/dsps_public_sw/apps_processors/Audio_soc_example/1_00/index_FDS.html

Installation, Building and Usage

Refer to the Release Note for the version provided in the SDK package or from the download page above.

NOTE At a minimum, the Advanced Linux Sound Architecture (ALSA) driver support for your device must be disabled in the target Linux kernel for the application to function properly. Depending on the device, other target Linux drivers might also need to be disabled. Specific information can be found in the Release Notes for this package.

Useful pages

• Debugging the DSP side of a DSPLink application on OMAP-L138 using CCS