Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

Configuring Codec Engine in Arm apps with createFromServer

From Texas Instruments Wiki
Jump to: navigation, search


This feature allows the Codec Engine user to configure their entire Arm application engine with a single line of code: instead of loading codec modules, creating an engine with an array of codec modules and names, and setting up the DSP combo/server memory map info, now the user can merely point to where the DSP server package is and have the remote engine automatically configured.

This eliminates memory map inconsistencies and requires a lot less typing!

Note that this feature only applies to ARM+DSP devices such as the DM644x, DM6467, and OMAP3. DSP-only or ARM-only devices have no concept of servers.

Usage: Configuring the ARM-side application

To configure the entire Engine in your app.cfg file you can utilize the Engine.createFromServer() function. For example, the .cfg file for the video_copy ARM-side app (ti/sdo/ce/examples/apps/video_copy/*) looks as follows: -

var Engine = xdc.useModule('ti.sdo.ce.Engine');
var myEngine = Engine.createFromServer(
    "video_copy",        // Engine name (as referred to in the C app)
    "./video_copy.x64P", // path to server exe, relative to its package dir
    "ti.sdo.ce.examples.servers.video_copy.evmDM6446" // server package

This configures your ARM app to have access to all the codecs available in the DSP server, and to use the same memory map for which the DSP server is configured.

You must have the server package as well as all the codec packages used by the server in your package path (XDCPATH). Just like before.

Usage: Building DSP server (codec combo) to enable createFromServer() on the Arm

On the server side, to enable use of this feature by the Arm app you must:

  1. use Codec Engine >= 2.0
  2. build your DSP server before building the Arm app
  3. have your DSP server in a package. You will have this if you base your server build off of any CE example, or use the Codec Engine "GenServer" Wizard, or you can see details below how to make sure your server is packaged.

Finding out what's in the DSP server combo

To find out what codecs your DSP server contains, look at the file package/info/(serverName).DataSheet.html inside the server's package. It lists all the codecs, their configuration, the server memory map, and the hardware resources that the server uses.

Here's a screenshot of a sample combo data sheet. An example of a full datasheet is here.

DecodeCombo x64P DataSheet html ScreenShot.jpg

This is very useful data! You can now pick up an arbitrary server and see exactly what's in it without requiring (error-prone!) user-documentation! Seeing the resource configuration (memory, DMA etc) might also save hours of painful debug later on!

This feature was added in Codec Engine 2.10.

Adding local codecs to engine configured with createFromServer()

To add local codecs to an existing Engine, add them to the algs array of the Engine you created. Here is an example of how to add local audio copy decoder and encoders to the ARM-side video_copy application configured through Engine.createFromServer():

// add remote codecs from the DSP server to the engine
var Engine = xdc.useModule('ti.sdo.ce.Engine');
var myEngine = Engine.createFromServer(
    "video_copy",        // Engine name (as referred to in the C app)
    "./all.x64P",        // path to server exe, relative to its package dir
    "ti.sdo.ce.examples.servers.all_codecs" // server package
// add 2 local ARM codecs -- audio_copy decoder and encoder -- to myEngine
var AUDDEC_COPY = xdc.useModule('ti.sdo.ce.examples.codecs.auddec_copy.AUDDEC_COPY');
var AUDENC_COPY = xdc.useModule('ti.sdo.ce.examples.codecs.audenc_copy.AUDENC_COPY');
myEngine.algs[ myEngine.algs.length++ ] = {
    name: "auddec_copy",
    mod: AUDDEC_COPY,
    local: true
myEngine.algs[ myEngine.algs.length++ ] = {
    name: "audenc_copy",
    mod: AUDENC_COPY,
    local: true

Adding a memory segment when using createFromServer() (for advanced users)

Most users would never want to do this, but there may be cases where a user would want to define extra custom memory segments on the DSP beyond the ones that are typically defined in every standard DSP server (i.e. DDR2, DDRALGHEAP, RESETCTRL, etc., which are auto-generated by the Server Package Wizard). One such occurrence is when someone wants to, for instance, have the linker directly place code and data into internal L1/L2 memory instead of using it as shared scratch or cache memory. Doing so requires defining modifying the DSP/BIOS (.tcf) configuration file to add an extra memory segment.

In CE 2.0, when createFromServer() is used, all memory segments defined in the DSP/BIOS (.tcf) configuration file of the DSP server are automatically configured into DSPLINK. The server integrator simply needs to define the segment in the .tcf file. For example, if the server integrator wants to add a memory section called IRAM on the DM6446 that defines the internal memory area not being used by the L2 cache, he can do the following in the DSP/BIOS (.tcf) configuration file:

// Set L2 cache to 32k, which automatically creates a section called IRAM in DSP/BIOS for the remaining 32k
var device_regs = {
    l2Mode: "32k"
var params = {
    clockRate: 594,
    catalogName: "ti.catalog.c6000",
    deviceName: "DM6446",
    regs: device_regs,
    mem: mem_ext
utils.loadPlatform("ti.platforms.generic", params);
// Putting some code into the IRAM memory region

DSPLINK would automatically be able to access the IRAM segment when loading the COFF file, thanks to the use of createFromServer().

Note for CE 2.10 users: Currently there is a bug where customized internal memory segments to the DSP are not automatically added by createFromServer as in the procedure above. These memory segments would need to be added manually in the application's cfg file, immediately after the call to createFromServer(). E.g.:

var Engine = xdc.useModule('ti.sdo.ce.Engine');
var demoEngine = Engine.createFromServer(...);
 * Add an internal memory segment at address 0x11818000 of size 0x10000. Must match .tcf file
 * of DSP server
demoengine.armDspLinkConfig.memTable[ "IRAM" ] = {addr: 0x11818000, size: 0x10000, type: "other"}

(Remember that most servers don't load code/data to internal memory (including the DVSDK servers) so this issue only affects custom servers that directly use the linker to place code/data in internal memory or some other 'customized' memory segments defined by the user in the .tcf file. createFromServer() works just fine for a large majority of our users who use L1 and L2 memories as shared scratch memory heap and cache.)

Note for CE 2.20 users: There is a bug in this version on OMAP platforms that prevents MMU mapping of the DSP internal memory range 0x107F8000 to 0x10F18000. Users are urged to upgrade to CE 2.21 that provides a fix for this issue and is based on a version of DSPLINK compatible with the fix.

Creating a DSP server package and its .tar release to hold the server and the info files for Configuro-based builds

Configuro-using makefiles that build DSP servers are on their own when it comes to creating a server release package. Here's an example of how it may look like -- here we auto-generate a RTSC package from the given package name $(SERVER_PKG), given server executable $(SERVER_EXE), and config name $(CONFIGPKG):

SERVER_PKG := ti.sdo.ce.examples.servers.video_copy.evmDM6446

SERVER_PKG_ARCHIVE := $(subst .,_,$(SERVER_PKG)).tar

# create server release package and archive it; the package
# contains the executable and some meta-info files
        @echo "Creating server release:"
        @rm -rf package package.*
        @echo "package $(SERVER_PKG) {}" > package.xdc
        @echo "Pkg.otherFiles = ['./$(SERVER_EXE)','package/info']" > package.bld
        @mkdir package ; cp -R $(CONFIGPKG)/package/info package
        @$(XDC_INSTALL_DIR)/xdc XDCPATH="$(XDC_PATH)" release
        @rm -f package.bld package.mak .[idle]*

Evaluation & production servers in different directories

What happens if the server producer does something like this in their package.bld package build script?

Pkg.addExecutable( "server_eval/" + serverName, targ, targ.platform,
            tcopts: "-Dxdc.cfg.check.fatal=false",
            cfgScript: "server.tcf",
            cfgArgs: '{profile: "' + arguments[0] + '"}',
            lopts: "-l link.cmd",
        addObjects( [
        ] );

The resulting .x64P executable will end up in server_eval/

When you build the GPP end-application you might get an error...

js: "/home/user/codec_engine_2_00/packages/ti/sdo/ce/Engine.xs", line 139: exception
from uncaught JavaScript throw: Error: server info
file '/home/user/workdir/testProject_070813/ce2x_xdc3x_wizard/packages/ti/sdo/servers/
does not exist; specified serverExecutable='./mpeg4dec_unitserver_evmdm6446.x64P',
verify that your server package has been properly built and released.

Now what? Well, the end-application was probably configured as follows: -


This configuration says to our tooling "I'll go look for the DSP server image 'mpeg4dec_unitserver_evmdm6446.x64P' in its current directory, located in package 'ti.sdo.servers.mpeg4dec_unitserver_evmdm6446'". But since the executable is 1 level deeper the build fails.

To fix this simply modify the app.cfg script as follows: -


The .x64P DSP executable will then be found, and so will it's info.js file supplying all the codec & memory map information.

Don't forget to match up engine names!

Nothing changes from Engine.create to Engine.createFromServer with regards to "engine name" matchup requirements. The name you provide in the first argument to createFromServer must match the engine name used in the application. Otherwise you'll get an error message similar to below: -

[DVEVM-ST-ERROR]: dvevmStEngine.c: Engine <mpeg4dec_engine> open failed. Status => 1
[DVEVM-ST-ERROR]: dvevmStVidPlay.c: Unable to initialize Codec Engine <mpeg4dec_engine>

TI's Digital Video Test Bench is quite flexible here. Either from the command line or a script (.dvs file), you can specify the engine name e.g. via...

setp engine name mpeg4dec_engine

However the DVSDK demos require specific engine names i.e.

DVSDK demo Engine Name used
decode decode
encode encode
encodedecode encodedecode

Pretty self-explanatory as you can see!

Keeping the same build script across different Codec Engine versions

What happens if you have clients on Codec Eng 1.20.02, 2.0 and 2.10? You want the customers on CE 2.x to be able to take advantage of new features like createFromServer() but you want 1 package.bld that "just works" for all 3 CE versions above.

The RTSC Codec & Server Wizards solve this problem by generating the following server package.bld

 * If using >= CE 2.0 include info.js createFromServer support to allow client
 * Engine to automatically get the right memory map and codec package info.
 * If using <= CE 1.20 create an empty directory so avoid build errors.
    var createDirectory = new"package/info").mkdirs();
}catch(e) {};

As indicated in the comments it will "just do the right thing" in CE 2.0 i.e. generate the information-file in package/info that createFromServer() consumes. However on CE 1.20 this feature did not exist. So we basically make an empty directory to avoid build errors.

Why is this try-catch block required at all you may ask? It's necessary at the point where you xdc release a server/combo package - you have to make sure the information-file gets included in the resulting tarball.

Advanced: overwriting fields, creating multiple engines

What Engine.createFromServer() returns is an instance of an Engine, with all fields pre-populated to match what's recorded at DSP server build time. You are, however, free to overwrite any of the fields in such engine instance object. For example, you can add local algorithms or change names of remote algorithms.

You can also configure your application to create multiple engines from multiple server info files; simply use a different name for each engine.

Changing the Server Executable Location

By default, the Engine that is createFromServer()'d is configured to look for the DSP image on the target in the current directory. In other words, if the server is some package "bin/bar.x64P", the app will be configured to load "./bar.x64P", not "./bin/bar.x64P". To overwrite this setting, you can define myEngine.server to contain a different path for the DSP server. This can be useful if you want multiple applications in different directories to use the same server without having a copy of the server executable in each directory, or if you want to be able to launch an application from any directory without having to worry about the server executable being in the same directory.

Adding this to the earlier example, let's say you want to run using the server executable: /some_where_else/video_copy.x64P

var Engine = xdc.useModule('ti.sdo.ce.Engine');
var myEngine = Engine.createFromServer(
    "video_copy",        // Engine name (as referred to in the C app)
    "./video_copy.x64P", // path to server exe, relative to its package dir
    "ti.sdo.ce.examples.servers.video_copy.evmDM6446" // server package
myEngine.server = "/some_where_else/video_copy.x64P";

In this case there need only be one copy of the video_copy.x64P executable in the "some_where_else" directory. Any application that was built using the settings above could be executed from any directory and would still be able to find the server executable because the absolute path is specified in the configuration file.

NOTE: You could also use a symlink to allow an application to point to a server executable in another directory (see here). unlike the above solution though, this requires that you create a symbolic link to the server in each directory where the ARM side application is being executed.

Configuring DSP Link information for each server

In CE 1.20, a feature was introduced to avoid rebuilding DspLink when the memory map of the DSP server is changed: the user could specify osalGlobal.armDspLinkConfig table in the Arm app.cfg file that contains the DSP memory table and any extra configuration fields, such as "doPowerControl".

In CE2.00, while the old, global osalGlobal.armDspLinkConfig is still supported for compatibility, now each Engine instance object that requires a server has an armDspLinkConfig object. (Not specifying it or using the old way will result in functional work but with warnings.) In other words, this field is now part of the engine instance object, for example

myEngine.armDspLinkConfig = {
    memTable: [
        ["DDRALGHEAP", {addr: 0x88000000, size: 0x07A00000, type: "other"}],
        ["DDR2",       {addr: 0x8FA00000, size: 0x00400000, type: "main" }],
        ["DSPLINKMEM", {addr: 0x8FE00000, size: 0x00100000, type: "link" }],
        ["RESETCTRL",  {addr: 0x8FF00000, size: 0x00000080, type: "reset"}],

The type of a memory entry deserves a bit of explanation here. "main" is the segment that corresponds to the one pointed to by the configuration property ti.sdo.ce.osal.bios.Settings.defaultMemSegId (or ti.sdo.ce.osal.Global.defaultMemSegId for older versions of CE 2.X). This is typically set to the "DDR2" segment, as defined in the DSP/BIOS (.tcf) configuration file. "link" corresponds to the shared memory area for DSPLINK, which is commonly named as "DSPLINKMEM". "reset" corresponds to the memory area that contains the reset vectors, which is commonly named as "RESETCTRL". Only one entry of each type among "main", "link" and "reset" can be defined in this array. Any other segments defined by the .tcf file that is used to hold code and data is of type "other".

By listing memory entries in this array, the user is informing DSPLINK of these memory regions, and DSPLINK can thus load code/data as specified by the DSP executable COFF file into these declared regions.

If you create your engine object with Engine.createFromServer(), the DSP memory map will be automatically configured (you may want to configure any other fields, like doPowerControl, manually). However, if you create your engine objects "the old way", you can still configure the armDspLinkConfig object from the server info file, as in this example:

myEngine.armDspLinkConfig = {
    memTable: getDspMemTableFromServer("./video_copy.x64P", "ti.sdo.ce.examples.servers.video_copy.evmDM6446"),

This way you don't have to edit your Arm app.cfg file when you change the DSP memory map, you just need to rebuild it.

You can also add arbitrary segments to the map force DSPLink to map it to the Arm address space:

myEngine.armDspLinkConfig.memTable[ "mySegment" ] = {addr: 0x87F00000, size: 0x00100000, type: "other"}

(You will most likely never need this feature.)

Build log

As your ARM application builds, if you are configuring the engine from the server info file, the engine and codec info will be printed on the console, for instance:

configuring ceapp.x470MV from package/cfg/ceapp_x470MV.cfg ...
Info: Configuring engine named 'video_copy' from the info file for DSP server './video_copy.x64P',
          located in package 'ti.sdo.ce.examples.servers.video_copy.evmDM6467':
      Target app will look for the DSP server image 'video_copy.x64P' in its current directory.
      Adding codec 'viddec_copy' (ti.sdo.ce.examples.codecs.viddec_copy.VIDDEC_COPY), scratch groupId=0
      Adding codec 'videnc_copy' (ti.sdo.ce.examples.codecs.videnc_copy.VIDENC_COPY), scratch groupId=0
Info: Reading DSP memory map from the info file for DSP server './video_copy.x64P',
      located in package 'ti.sdo.ce.examples.servers.video_copy.evmDM6467':

Codec packages mismatch check

Sometimes it happens that a server was build with one version of some codec, and the Arm app integrator has a different version of that codec. Both the old and the new codec (typically new being used for the server, old for the Arm app) are often in the same package, so the build succeeds, but the codec creation on the DSP fails with a cryptic message.

To prevent this surprise, the JSON file now keeps, for each codec, the codec's basic properties as listed in the ti.sdo.ce.ICodec interface: ialgFxns, idma3Fxns, uuid, rpcProtocolVersion, serverFxns, stubFxns. When the createFromServer() method is called, it checks if the server's codec had the same basic properties as the same-named codec found in the arm app's package path. If any of these three doesn't match: ialgFxns, rpcProtoclVersion, uuid, a big warning is printed that the codec won't be able to be created.

(Could be an error, but some people may choose to proceed anyway and just not call those codecs from their C app.)

Here's such an example, from a build log:

Info: Configuring engine named 'video_copy' from the info file for DSP server './video_copy.x64P',
          located in package 'ti.sdo.ce.examples.servers.video_copy.evmDM6467':
      Target app will look for the DSP server image 'video_copy.x64P' in its current directory.
      Adding codec 'viddec_copy' (ti.sdo.ce.examples.codecs.viddec_copy.VIDDEC_COPY)
      Adding codec 'videnc_copy' (ti.sdo.ce.examples.codecs.videnc_copy.VIDENC_COPY)

WARNING: Codec 'videnc_copy' from package 'ti.sdo.ce.examples.codecs.videnc_copy' found on your package path in directory '/db/atree/davor/ce-g16x/src/codec_engine_2_00_00_15/examples/ti/sdo/ce/examples/codecs/videnc_copy/' is different from the codec that was used to build the server. You will NOT be able to create and run this codec from your application. Details:
   module name: 'ti.sdo.ce.examples.codecs.viddec_copy.VIDDEC_COPY'
   ialgFxns:           server: 'VIDDECCOPY_TI_IALG', app: 'VIDDECCOPY_TI_VIDDECCOPY'
   rpcProtocolVersion: server: 3, app: 3
   uuid:               server: undefined, app: undefined
   package version:    server: [], app: []

Format of the DSP server data file used by createFromServer()

You probably do not need this information, but here it is anyway: the data file that createFromServer() reads when filling up the Arm-side app's engine with DSP codecs that was created at build time is located in package/info/(serverName).info.js file inside the server's package. It's a JavaScript file, in the ASCII format called JSON (JavaScript Object Notation, a human-readable alternative for HTML). Any modifications to this file will be picked up by the createFromServer() at Arm app build time, so this file should not be changed.

Below is a sample server data file:

    "server algorithms": {
        "programName": "video_copy.x64P",
        "algs": [
                "mod": "ti.sdo.ce.examples.codecs.viddec_copy.VIDDEC_COPY",
                "pkg": "ti.sdo.ce.examples.codecs.viddec_copy",
                "pkgVersion": [
                "rpcProtocolVersion": 3,
                "ialgFxns": "VIDDECCOPY_TI_VIDDECCOPY",
                "threadAttrs": {
                    "priority": 2,
                "groupId": 0,
                "serverFxns": "VIDDEC_SKEL",
                "stubFxns": "VIDDEC_STUBS",
                "name": "viddec_copy",
                "mod": "ti.sdo.ce.examples.codecs.videnc_copy.VIDENC_COPY",
                "pkg": "ti.sdo.ce.examples.codecs.videnc_copy",
                "pkgVersion": [
                "idma3Fxns": "VIDENCCOPY_TI_IDMA3",
                "rpcProtocolVersion": 3,
                "ialgFxns": "VIDENCCOPY_TI_VIDENCCOPY",
                "threadAttrs": {
                    "priority": 2,
                "groupId": 0,
                "serverFxns": "VIDENC_SKEL",
                "stubFxns": "VIDENC_STUBS",
                "name": "videnc_copy",
    "DSP memory map": [
                "type": "main",
                "addr": 0x8FA00000,
                "size": 0x00400000,
                "type": "reset",
                "addr": 0x8FF00000,
                "size": 128,
                "type": "other",
                "addr": 0x88000000,
                "size": 0x07A00000,
                "type": "link",
                "addr": 0x8FE00000,
                "size": 0x00100000,

An example : before and after createFromServer()

To put it in perspective here is a real world application (vendor names changed) config file before and after

Note : parts of the files have been trimmed...


var osalGlobal = xdc.useModule('ti.sdo.ce.osal.Global');
osalGlobal.runtimeEnv = osalGlobal.DSPLINK_LINUX;
/* get various codec modules; i.e., implementation of codecs */
var AAC_DEC = xdc.useModule('vendor.codecs.aac_dec.ce.AAC_DEC');
var AACLC_ENC = xdc.useModule('vendor.codecs.aaclc_enc.ce.AACLC_ENC');
var FLAC_DEC = xdc.useModule('vendor.codecs.flac_dec.ce.FLAC_DEC');
var H263_ENC = xdc.useModule('vendor.codecs.h263_enc.ce.H263_ENC');
var H264BP_DEC = xdc.useModule('vendor.codecs.h264bp_dec.ce.H264BP_DEC');
var H264BP_ENC = xdc.useModule('vendor.codecs.h264bp_enc.ce.H264BP_ENC');
var JPEG_DEC = xdc.useModule('vendor.codecs.jpeg_dec.ce.JPEG_DEC');
var JPEG_ENC = xdc.useModule('vendor.codecs.jpeg_enc.ce.JPEG_ENC');
var MP3_DEC = xdc.useModule('vendor.codecs.mp3_dec.ce.MP3_DEC');
var MP3_ENC = xdc.useModule('vendor.codecs.mp3_enc.ce.MP3_ENC');
var MPEG4_ENC = xdc.useModule('vendor.codecs.mpeg4_enc.ce.MPEG4_ENC');
var MPEG4SP_DEC = xdc.useModule('vendor.codecs.mpeg4sp_dec.ce.MPEG4SP_DEC');
var PCM_DEC = xdc.useModule('vendor.codecs.pcm_dec.ce.PCM_DEC');
var PCM_ENC = xdc.useModule('vendor.codecs.pcm_enc.ce.PCM_ENC');
var VORBIS_DEC = xdc.useModule('vendor.codecs.vorbis_dec.ce.VORBIS_DEC');
var WMA_DEC = xdc.useModule('vendor.codecs.wma_dec.ce.WMA_DEC');
var WMV9_DEC = xdc.useModule('vendor.codecs.wmv9_dec.ce.WMV9_DEC');
 *  ======== Engine Configuration ========
var Engine = xdc.useModule('ti.sdo.ce.Engine');
var myEngine = Engine.create("av_combo_server", [
    {name: "aac_dec", mod: AAC_DEC, local: false},
    {name: "aaclc_enc", mod: AACLC_ENC, local: false},
    {name: "flac_dec", mod: FLAC_DEC, local: false},
    {name: "h263_enc", mod: H263_ENC, local: false},
    {name: "h264bp_dec", mod: H264BP_DEC, local: false},
    {name: "h264bp_enc", mod: H264BP_ENC, local: false},
    {name: "jpeg_dec", mod: JPEG_DEC, local: false},
    {name: "jpeg_enc", mod: JPEG_ENC, local: false},
    {name: "mp3_dec", mod: MP3_DEC, local: false},
    {name: "mp3_enc", mod: MP3_ENC, local: false},
    {name: "mpeg4_enc", mod: MPEG4_ENC, local: false},
    {name: "mpeg4sp_dec", mod: MPEG4SP_DEC, local: false},
    {name: "pcm_dec", mod: PCM_DEC, local: false},
    {name: "pcm_enc", mod: PCM_ENC, local: false},
    {name: "vorbis_dec", mod: VORBIS_DEC, local: false},
    {name: "wma_dec", mod: WMA_DEC, local: false},
    {name: "wmv9_dec", mod: WMV9_DEC, local: false},
myEngine.server = "./av_combo_server.x64P";
myEngine.armDspLinkConfig =  xdc.useModule("ti.sdo.ce.ipc.dsplink.Settings").DEFAULT_ARMDSPLINKCONFIG['TMS320C3530'];
myEngine.armDspLinkConfig.memTable["DDR2"] = {
    addr: 0x87800000,
    type: "main"


/* set up OSAL */
var osalGlobal = xdc.useModule('ti.sdo.ce.osal.Global');
osalGlobal.runtimeEnv = osalGlobal.DSPLINK_LINUX;
 *  ======== Engine Configuration ========
var Engine = xdc.useModule('ti.sdo.ce.Engine');
var myEngine = Engine.createFromServer(
	"av_combo_server",		// define engine name (app needs to use same name)
	"./server_production/av_combo_server.x64P",		// path to server exe relative to package dir
	"vendor.servers.av_combo_server"		// server package

Much simpler!

Some observations of the simplifications in the new config: -

  • The OSAL can be set entirely by just setting the runtimeEnv. When we set it to DSPLINK_LINUX the DSPLINK package's runtimeOS is set under the covers for us. We explicitly mention this because many config files set the IPC - 99% of the time this isn't necessary because you'll typically be using the DSPLINK IPC in Arm+DSP systems. The osalGlobal.runtimeEnv = osalGlobal.DSPLINK_LINUX; setting is therefore sufficient. You only need to tweak the ipc.Settings in the rare cases where a different IPC is in use.
  • No need to respecify the 17 codecs we included in the server.
  • No need to respecify the memory sections such as DDR2.

More data on recent config improvements can be found on the CE Config Updates article.