From Texas Instruments Embedded Processors Wiki

Introduction

The typical release model for Texas Instruments codecs is in a RTSC codec package. In that package there is also a bunch of 'meta-data' in a ce/ sub-folder that communicates important data to the Codec Engine framework such as the getDaramScratchSize() method as shown here. Armed with this extra data the CE framework can do a better job allocating the right scratch memory, stack size and other resources for the algorithms in the system.

However there are many customers that have their own framework or are developing on platforms which do not have a DVSDK such as the TMS320C6455 device.

The purpose of this article is to show how to use the existing RTSC codec packages in a non-RTSC, non-Codec-Engine environment.

It is pretty simple :-)

What's in the codec package?

Let's look at an AAC audio decoder on the c64+ Instruction Set Architecture.

Let's briefly describe what's in here: -

• top-level directory dm6446_aachedec_1_22_000_evaluation - you'll find that all TI codecs use this convention i.e. platformname_codecname_versionnum_evaluation. FYI all of the audio (and speech and imaging) codecs from TI on the c64+ platform are platform-agnostic i.e. they can run on any c64+ variant such as DM6437, DM6446, OMAP3530 etc.
• \packages\ti\sdo\codecs\aachedec - this is the standard hierarchy for a RTSC package i.e.
  • packages - consistent top-level name for a 'repository'.
  • ti - vendor name
  • sdo - group name
  • codecs - type of content
  • aachedec - name of the codec
• app - this contains the Client sample application - a file I/O based example with a Code Composer Studio project (NOTE - the app directory may be removed in future codec packages and replaced directly with the 'Client' directory)
• docs - pretty obvious what's in here :-)
• lib - contains the prebuilt XDAIS-compliant codec library, in this case aacdec_tii_e.l64P (the _e signifies evaluation version)
• ce - this directory contains the add-on meta-data for Codec Engine as briefly mentioned in the Introduction.
• package - a generated XDC directory

What do I really need as a non-RTSC, non-CE user?

Not much! In this example, to build your application you only need the following: -

• aachedec\lib\aacdec_tii_e.l64P - add this to your linker command file or linker tab in your CCS project. Point your -I include path to this lib directory.
• aachedec\iaacdec.h - optional - this is an add-on header which exposes extra functionality such as XDAS_Int32 PseudoSurroundEnableFlag; via it's extended parameters. Point your -I include path to this base directory. It's optional because you can use the codec perfectly well via its base XDM parameters exposed via the standard AUDDEC interface in xdais_n_mm\packages\ti\xdais\dm\iauddec.h.
• aachedec\app\Client\Build\AACADecApp.cmd - optional - this is the linker command file used in the sample Client/ application. However codecs are often sensitive to cache placement from a performance perspective so you may want to copy-paste the relevant parts into your end-application's cmd file (e.g. if there is a GROUP directive, copy that and it's contents to ensure that exact memory placement layout)

So...you might ask "why do I need all this other baggage?". Fair question however, to compare, there's probably 1 gb of stuff in C:/WINDOWS that you may or may not use. There's value in just having 1 package, 1 version from a maintenance and test standpoint. The extra stuff won't eat much hard-disk space.

What does the Client sample app do?

It is a file-driven application i.e. in the above case it reads in frames of an encoded AAC file, decodes them using the AAC HE Decoder library, and optionally outputs the decoded result to a file.

Typically it does not use DSP/BIOS although the BCACHE module is used (it has no configuration parameters nor deep dependencies hence can be used standalone).

It does not leverage any PSP peripheral drivers, nor is it real-time. It can typically be run on a Simulation platform such as the c64+ Cycle Accurate Simulator in CCS.

It is intended to show a simple working example. It also helps with understanding the application side usage of XDM, although the DMAI sample applications are a better reference for 'XDM compliance'.

How do I know which XDM / VISA interface version this codec implements?

Good question. This is important to know so that your application matches up to the codec package from an interface perspective. IAUDDEC is not the same as IAUDDEC1. Do not try to 'cram in' an IAUDDEC1 based codec into an application that is expecting IAUDDEC codecs!!

Unfortunately, at this time, there is no easy way for the build system to say "you're using a mismatched interface" especially in a non-RTSC, non-Codec-Engine environment.

Here are some methods to confirm the XDM interface version: -

• Read the docs - the 1st line in the Datasheet for this codec clearly states eXpressDSP™ Digital Media (XDM 0.9 IAUDDEC) compliant
• Check the sample application. In this example TestAppDecoder.c shows: -

IAUDDEC_Fxns *iaudDecFxns;

• Look at aachedec\ce\AACHEDEC.xdc. It will directly show which interface the codec implements: -

metaonly module AACHEDEC inherits ti.sdo.ce.audio.IAUDDEC
{
    readonly config ti.sdo.codecs.aachedec.AACHEDEC.Module alg =
        ti.sdo.codecs.aachedec.AACHEDEC;
 
    override readonly config String ialgFxns = "AACDEC_TII_IAACDEC";
}

• Run the Unix/Linux strings command: -

[alan@lab1 lib]$ strings aacdec_tii_e.l64P | grep AUDDEC

IAUDDEC_Cmd
IAUDDEC_Status
IAUDDEC_Status
IAUDDEC_Fxns
IAUDDEC_Obj
IAUDDEC_Handle
IAUDDEC_DynamicParams
...

An XDM 1.0 version would obviously show the AUDDEC1_ prefix instead.

I changed my mind. I do want to use this codec within Codec Engine

Aha! Then read the wiki topics on the RTSC Codec and Server package wizards. These provide all the details on exactly what the rest of the codec package does, and how to use it from a system integrator perspective.

For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article How to use a RTSC codec package in a non-RTSC environment here.

	Links
	ARM Microcontroller MCU ARM Processor Digital Media Processor Digital Signal Processing Microcontroller MCU Multi Core Processor Ultra Low Power DSP 8 bit Microcontroller MCU 16 bit Microcontroller MCU 32 bit Microcontroller MCU

Comments

Comments on How to use a RTSC codec package in a non-RTSC environment

Joerngr said ...

Joerngr said ...