I'm checking to see why it can't be found by searching the web site.
It's included in the xDAIS Developer's Kit 5.00 here:
https://www-a.ti.com/downloads/sds_support/targetcontent/XDAIS/index.html
... and is also included in the xDAIS product (look for the xdais_5_00
directory) if you have a
Yes.
Chris
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of [EMAIL PROTECTED]Sent: Thursday,
September 21, 2006 1:30 AMTo:
davinci-linux-open-source@linux.davincidsp.comSubject:
Memory_contigAlloc()
As I know, we need to use Memory_configAlloc()
Title: RE: DSP Stack Memory Map
The copy codec packages(e.g. codecs.videnc_copy)
include libraries - and even sources(!), and are there as examples for the Codec
Engine product.Provided you have all the DSP-side requirements
(provided with the DVSDK) like DSP-sidecompilers, DSP/BIOS,
I resolved a "Bus error" recently in one
of the Codec Engine examples (examples/apps/speech/linuxonly).I can
tell you what I was doing wrong andmy solution- perhaps it's similar
to your situation and can be solved similarly.
Theexample had declared data buffers as static global
arrays of
You might learn more about the error by enabling the various tracing
mechanisms in the Codec Engine. Often, just setting the CE_TRACE
environment variable to turn on all trace levels for all trace masks
(*=01234567) will reveal something interesting. I often do this by
simply setting the
In short, your codec's getLibs() function, in package.xs, should be sure
to only return a library name when targets it supports are requested.
That is, getLibs() should look like this if it only supports C64P
targets:
function getLibs(prog)
{
var name;
if (prog.build.target.isa == 64P) {
Unfortunately, VIDENC_OutArgs.reconBufs is not supported in Codec Engine
when the codec is remote and the application is running on an OS with
virtual memory (like Linux) - exactly our typical DVEVM environment.
The rationale is that today's xDM interface (version 0.9) defines no
formal
Read the error message.
config.bld: Error: compiler path for C6x DSP tools points to
an incorrect directory
(C64P.rootDir='/db/toolsrc/library/tools/vendors/ti/c6x/6.0.3/
Linux'). Edit file
'/opt/dvevm_1_10/codec_engine_1_02/examples/user.bld' and
correct the line that sets the
Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Saturday, November 25, 2006 9:41 AM
To: Ring, Chris
Subject: Your message to Davinci-linux-open-source awaits
moderator approval
Your mail to 'Davinci-linux-open-source' with the subject
RE: cache coherency problem
For the pure DSP Link samples, you don't need the CMEM driver. DSP Link has no
dependency on CMEM.
And for completeness,
* Codec Engine (for DM644x) has a dependency on both CMEM and DSP Link.
* The DVEVM demos have a dependency on Codec Engine.
Chris
-Original Message-
From:
To: Ring, Chris; [EMAIL PROTECTED]
Subject: RE: cache coherency problem
hi, Chris and santhoshk, sorry for my carelessness.
At the moment of sending the last mail, I forget one thing:
there is a
branch in my codec where CPU will write the input buffer, ( since this
branch is added
I know it's very verbose output, but not-so-hidden in your output is
this line:
ti.targets.C64P: warning: exec of
'/home/nandol52/dvevm_1_10/cg6x_6_0_3/bin/cl6x -version'
failed:java.io.IOException: java.io.IOException:
/home/nandol52/dvevm_1_10/cg6x_6_0_3/bin/cl6x: cannot execute
That's
Two quick ones:
1. Looks like your CMEM kernel module needs to be rebuilt against
your new(?) Linux kernel (error in #4)
2. In the default configuration, the DSP Server must be in the same
directory as the Linux application (error in #6) - you did build the
examples/servers (which requires
Independent of the codec engine examples, can you simply execute the following
command:
/home/dan/dvevm_1_10/cg6x_6_0_3/bin/cl6x -version
I'm wondering if your codegen installation is corrupted (perhaps the
executables aren't marked executable?).
Chris
-Original Message-
Haven't tried it, but for those interested, the cmem function for
virt-phys translation is below. Anybody familiar with Linux know if
anything's changed in recent kernels that would cause this technique to
fail? Or want to offer up a better way to do this translation?
Can anyone confirm this
Sanity check, in drawDynamicData you're calling showJPEG() with one
argument, instead of the 2 it expects... then, in showJPEG(), you're
walking into an array offset by the unprovided argument
(simpleScreens[screenIdx]). Because screenIdx is random and
uninitialized, simpleScreens[screenIdx] may
1. If you _just_ want to rebuild the ARM-side examples, you can comment
out C64P and Linux86 from the Build.targets array. What are these
targets?
* C64P == the DSP side of DaVinci target. It's one of TI's DSP
processor families
PROTECTED]
Sent: Sunday, January 07, 2007 5:55 AM
To: Preissig, Steve; Ring, Chris;
davinci-linux-open-source@linux.davincidsp.com
Subject: Is Code Engine necessary
Hi Steve, Chris and everyone,
For the last couple of weeks, I have been
A bit long, but hopefully worthwhile...
Question 1. A couple thoughts on how you could make this happen.
Jean-Michel's suggestion to add the common speex-base.l64P to the linker
cmd file should work, but I'll suggest 2 alternatives.
A. You _should_ be able to create a single multi-codec
From: yoni l [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 14, 2007 12:59 AM
To: Ring, Chris
Subject: Re: codec engine
Hi Chris,
1. Does the examples\codecs\viddec_copy\ directory
Briefly, you have the freedom to set this up to meet your system's memory
constraints. You'll have to identify your application's memory constraints and
configure CMEM appropriately.
And some background to help you better understand what's going on in CMEM...
Some details in this thread:
Are you using multiple processes in your app?
I'm not a Link expert, but I think these assertions are thrown when you
call MSGQ_Get() (which the internals of the VIDENC_create()/delete()
APIs use) from a different process than you called MSGQ_Open() with
(which Engine_open() does).
(Link experts
Yes. This app note describes the few steps necessary in section 3.2:
http://focus.ti.com/lit/an/spraaf6/spraaf6.pdf
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of ? ?
Sent: Sunday, January 21, 2007 7:32 PM
To:
before, so if they continue, I'm hoping someone more
familiar with Link can chime in.
Chris
-Original Message-
From: Kushal Dalal [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 21, 2007 9:29 PM
To: Ring, Chris; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: Error messages
When you utilize Memory_contigAlloc(), you're building in a dependency
on a Codec Engine API. This API, when on Linux, simply wraps the CMEM
APIs.
Because 1) this app may not care about cross-OS compatibility, and 2)
you want to minimize dependencies - always a good goal, you may want to
just
Creating a DSP-side Codec Server requires codegen tools. You'll be
compiling and linking a DSP-side executable. Per your directed
questions...
I am going to build a new codec server without changing memory
map,so can i do it with dvevm software?
1. No. My understanding is
Per #2, see here:
http://www.mail-archive.com/[EMAIL PROTECTED]
om/msg00339.html
Some Linux distro's (Suse Linux and MV Windows/cygwin at least?) don't
support install -C. You can safely remove the '-C' option from any
makefiles you find it in. I think this was fixed in the official DVEVM
1.10
Local codecs are codecs that run on the same processor as the
application. Remote codecs are codecs that run on a different processor
than the application.
In single processor architectures (e.g. DM643x), all codecs are local.
In DM644x, the application processor is typically the ARM, and
FWIW, I'm planning on distributing the sources to at least the skeletons
in future version of Codec Engine. You can then see the cache
operations in all their glory.
Not sure which version of CE you have, but here is a snippet of the
SPHENC skeleton (DSP-side). In red, I've highlighted the
Start here:
http://www-s.ti.com/sc/techlit/sprued6
I know others here have done this, so you can post more directed
questions here and this list can try to help.
Chris
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of mafaqing
Not exactly sure what you're trying to do... but I'll state some thoughts.
1. The inBufs and outBufs arguments to process() are an array of buffers -
up to XDM_MAX_IO_BUFFERS (16). So, if you own the application, and the codec,
you can utilize the existing VISA APIs to pass multiple
Hmmm, have to be careful here.
The list of libraries to link in will vary with the application config.
For example, Andy, if you added a video codec to your application
config, you'd need to add video.a470MV. If you enabled debug libraries,
you'd have to switch most of the libraries in the
, March 14, 2007 12:46 AM
To: davinci-linux-open-source@linux.davincidsp.com
Cc: Ring, Chris; Andy Ngo
Subject: Re: Segmentation fault
Hi Andy and Chris,
Thanks for your reply.I tried to build application by linking
the libraries
Posting a reply to an earlier email with the same subject. The original
mail includes an 'adworks' footer I didn't want to download/redistribute
in my reply.
Q. Does anybody know which Codec Engine API call opens the device
/dev/cmem and the DSP/ARM trace files (cearmlog.txt, cedsp0log.txt,
If this is the scale Codec Engine application, you should:
1. Build the codec (codecs/scale)
2. Build the extension (extensions/scale)
3. Build the server (servers/all_codecs) - this creates all.x64P
4. Build the application (apps/scale) - this creates
app_remote.x470MV
When
The xDAIS 5.10 Developers Kit, available here:
https://www-a.ti.com/downloads/sds_support/targetcontent/xdais/index.html
... includes 'copy codecs' which implement the xDM 1.00 Beta interfaces. While
these codec examples implement the xDM 1.00 Beta interfaces (not xDM 0.9, like
your requested
5:50 AM
To: davinci-linux-open-source; Ring, Chris
Subject: RE: Problems of buliding codec engine examples
Hello,Chris
I'm sorry that there is something worng with my mail_server.
Below is my questions.
If I wnat to rebuild the dsp server, what tools should I have?
Can I rebuild
Can you turn on full tracing and post the trace log? Can you acquire
the DSP log as well? If so, can you rebuild your server with
DSKT2.debug = true and send the DSP log as well?
[ And if your codec uses DMA, configure DMAN3.debug = true in the
server also. ]
Are you changing the ARM-side
If by adding a parameter, you mean adding an argument to the process
function signature, no, you can't do that. The function signature is a
part of the IVIDENC_Fxns spec and can't be changed.
However, the structs passed into process (e.g. IVIDENC_InArgs) can be
'extended' by updating the .size
: Aysun Tasyapi [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 5:56 AM
To: Ring, Chris
Cc: [EMAIL PROTECTED]
Subject: İlgi: Add a new parameter
Hi Chris,
I am working with videnc_copy. I've added a new parameter to
VIDENC_InArgs.
When i call new paramaeter at the DSP side, i
Regarding the link error - paraphrased from the DSP/BIOS team:
That problem may be caused by linker not generating trampoline for
functions that we define as aliases within our generated .cmd file.
There is a related defect against the linker for this --
See below...
Chris
-Original Message-
From: Aysun Tasyapi [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ]
Sent: Friday, April 13, 2007 4:17 AM
To: Ring, Chris
Cc: [EMAIL PROTECTED]
Subject: İlgi: İlgi: Add a new parameter
Hi Chris,
I am sorry. But i can't still do.
I've
: Sunday, April 15, 2007 12:41 AM
To: Ring, Chris
Subject: CCS 3.2
Hi Chris
Whether there is a documentation about how i can to compile the
examples in CCS3.2?
___
Davinci-linux-open-source
wonder whether XDAIS 5.0 supports extension of *Inargs or not?
I must download XDAIS 5.10 ?
Best regards.
Aysun
2007/4/14, Ring, Chris [EMAIL PROTECTED]:
See below...
Chris
There is typically a loadmodules.sh script that needs to be run first - this
insmod's the cmemk.ko and dsplinkk.ko drivers appropriately configured for your
system.
Chris
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ??
Sent:
If you're using Codec Engine, the semantics are that the application (on the
ARM) provides both inBufs and outBufs to the DSP. If necessary, the app can
get a physically contiguous buffer with Memory_allocContig().
The DSP reads from inBufs and writes to outBufs. When *_process() returns to
into it. This will ensure
clear ownership, and can ensure that cache management (and read/write access)
can be done correctly.
Chris
-Original Message-
From: Jeremy [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 24, 2007 2:54 PM
To: Ring, Chris; davinci-linux-open-source@linux.davincidsp.com
Subject: Re
-source@linux.davincidsp.com
Cc: [EMAIL PROTECTED]; Ring, Chris
Subject: Codec Engine problem
Hi All,
I am developing application(arm side) on Davinci. I try to
use codec engine
APIs, and I face following problems after integrating Codec
engine in my
application.
I have listed down
There's some good stuff here:
http://www.elinux.org/Boot_Time
Chris
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
com] On Behalf Of Andy Ngo
Sent: Monday, July 09, 2007 1:09 PM
To: davinci-linux-open-source @linux.davincidsp.com
Also, cache management is often important to consider when going across
processor boundaries (and even across component ownership of buffers!).
Just posted this to try to capture many of the cache issues:
http://wiki.davincidsp.com/index.php?title=Cache_Management
Feel free to correct errors
Did you rebuild the DSP-side Server (*.x64P) with Link 1.40.05 and CE
1.20, too?
DSP Link libraries are linked into both GPP and DSP side executables, as
are Codec Engine (and Framework Components) libraries. AFAIK, the DVEVM
DSP-side binaries are provided pre-built, and there's [currently] no
Can you send the build log with the useModule error? Have you modified
the .cfg for the example your building?
Chris
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of yoni l
Sent: Sunday, July 15, 2007 8:56 AM
To:
A return code of -3 is XDM_EUNSUPPORTED. Maybe your inArgs aren't
supported by this particular codec.
Sometimes the codecs report further details in the outArgs.extendedError
field; you can consult the codec's users guide as well for
codec-specific return codecs in this .extendedError field.
Some details on rebuilding Link are here:
http://wiki.davincidsp.com/index.php?title=Changing_the_DVEVM_memory_map
Chris
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of John Sample
Sent: Wednesday, August 08, 2007 1:54 PM
Does the ARM really have to be disabled?
See the instructions here - You should be able to run in your nice Linux
world and still use CCS to debug your codec:
http://wiki.davincidsp.com/index.php?title=Debugging_the_DSP_side_of_a_C
E_application_on_DaVinci_using_CCS
An alternative, though it
Which version of the DVEVM (specifically, Codec Engine, and XDC Tools)
are you using?
If you only want to build the DSP-side server (i.e., just C64P tools),
this should work fine on Windows. Very early releases of the XDC Tools
had mixed support for building ARM content on Windows - but later
This is a FAQ:
http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ#Why_do_I_get
_error_0x80008013_during_Engine_open.28.29
Typically caused by a memory map mismatch between Server and app. You
can refer to the checklist here to doublecheck you rebuilt your
server/app correctly:
The technique is described here:
http://wiki.davincidsp.com/index.php?title=Extending_data_structures_in_
xDM
There's no extra work for adding a codec with extended fields into a
server or app. The app just has to remember to set the .size field
correctly.
Chris
, 2007 8:52 AM
To: Ring, Chris; davincimail
Subject: Re: Example using extended xDM codec
Thank you, that turns it on indeed.
The application succeeds now to open the codec engine, however
it hangs in the codec. I have two questions
From: Dorel [mailto:[EMAIL PROTECTED]
Sent: Friday, September 28, 2007 7:02 AM
To: Ring, Chris; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Example using extended xDM codec
Thanks Chris, that worked.
Now, when
Fundamentally, you're getting this error:
--
can't find package 'ti.sdo.codecs.jpegenc.ce' along the path
'/home/davinci/dvevm_1_20/codec_engine_1_10_01/examples/apps/jpegencdec/
../..;/home/davinci/dvevm_1_20/codec_engine_1_10_01/packages;/home/davin
If you're using Codec Engine (which version?), can you also provide your
DSP Server's .cfg script and the generated .map file (probably in the
server's generated package/cfg/* directory)?
I'd like to understand what codecs are in the system, and what resources
they may be sharing (e.g. DSKT2
Good thread - thanks everyone for contributing. My 2 cents...
CMEM (or something like it) is needed to do virt2phys (and vice-versa)
address translation on arbitrary physically contiguous buffers, not just
those allocated by CMEM. This is because often the buffers destined for
the DSP (and/or
The Codec Engine framework can support this (Just call VIDENC_create() 4
times from the same thread to get your 4 handles)...
... but I'm not sure whether you'll run out of resources (DMA, memory,
etc) on the DSP for those 4 instances. That will depend on the resource
requirements of your
Just to help avoid confusion, in TI supported releases of CMEM, CMEM
_can_ get the physical addresses of non-CMEM buffers. This,
unfortunately, only includes 2.6.10-based kernels... but since that's
the kernel used in the DVEVM, that includes the majority of users.
The DVEVM demos use this
Recent releases of CE removed app.x64P as it's a confusing
configuration. What you really want is app_local.x64P, and look at
local.cfg (not app.cfg) for reference. If you want to be further
confused, read below the line. ;)
--
Mainly for _testing_
It looks like the call's failing before the ARM-side stubs get a chance
to send the request to the DSP side. I'm inferring this because I don't
see a Comm_alloc() or Comm_put() between the IMGENC_control() enter and
exit calls - these Comm messages are how the ARM-side stubs and DSP-side
Good question - we should help clarify this in the docs.
As you know, on the ARM, Memory_allocContig() is handled by CMEM - and
you give it memory via insmod config params.
On the DSP-side Memory_allocContig() is implemented on top of DSP/BIOS -
and you give it memory via the BIOS .tcf script.
There are some of the finer details here:
http://wiki.davincidsp.com/index.php?title=Cache_Management
In short, however, Codec Engine's _only_ cache management is in the
DSP-side skeletons - that is, on the remote processor, managing data
buffers for remote algorithms. It never manages the
Can you reproduce this in hardware? We were able to reproduce it on the
simulator, but not on hardware - and we're wondering if we should file
this as a simulator bug.
Chris
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Ben White
Thanks!
We're currently creating a patch release (CE 2.00.01) to address a few
other minor issues reported, and will integrate this feedback as we put
that together. There will be some updates to the example build
structure, mainly to support building for a limited set of
devices/platforms
Yes, they are potentially different. This function is auto-generated,
depending on the executable's configuration. If the executable contains a DSP
server (e.g. the DSP-side servers/video_copy executable), CERuntime_init() will
create a Server thread.
The end user's main() - whether server
FYI, I've added this to the FAQ here:
http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of Ring, Chris
Sent: Sunday, December 16, 2007 7:02 PM
To: RyanYee/叶晔; davinci-linux-open
Often these modules (and all kernel modules, because of Linux's lack of any
binary compatibility support), require a rebuild if any kernel reconfiguration
or patching occurs.
While CE and DVSDK may provide pre-built binaries for convenience, it's good
practice to get a rebuild of these modules
There is some discussion of the cache maintenance overhead inherent in
multi-processor systems in the archives here:
http://linux.omap.com/pipermail/davinci-linux-open-source/2007-May/00327
0.html
There are some techniques to eliminate some of this cache maintenance if
possible, ranging from
Are you using CE 1.10 or 1.20? The first bit of your email says you're
moving to CE 1.20... but the autogenerated .xdl file is showing that
you're still using CE 1.10 (or at least the XDCPATH was pointing at CE
1.10 when the config step was run).
Also, which version of XDC Tools are you using?
The Multimedia APIs and Codec Engine Engine Frameworks is confusing
marketing-speak for simply the Codec Engine you know and love. I don't
know of any other Multimedia APIs being supported.
On the DM355, the codecs run in user mode, and are configured as 'local'
in the application's config
You're failing during the build of the x86 (native) examples. If you don't
care about these, you can simply comment out the Linux86 target from the
Build.targets array in examples/user.bld.
I've added some details about this to the CE FAQ here:
Can you help us understand your usage a little better (and which version
of CE you're using)?
VISA_create() is an SPI - System Programming Interface - used by
algorithm providers that are integrating non-xDM algorithms into the
Codec Engine environment. Is that what you're trying to do?
And
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 23, 2008 8:24 PM
To: Ring, Chris; davinci-linux-open-source@linux.davincidsp.com
Subject: RE: How to make CMEM cacheable on ARM side on DM6446?
Chris,
Thanks a lot!
I am using CE 2.0, XDC_3_00_2, bios_5_31_08 for a non-VISA
component. I
Glad to hear that worked for you - not too many users of that feature
just yet!
Detailed replies inlined below...
Chris
-Original Message-
From: Kumar Brajbhushan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 23, 2008 11:15 PM
To: Ring, Chris; davinci-linux-open-source
Ideally the don't-trust-TI-headers-to-do-the-right-thing workaround
won't be necessary. If it is, please report any issues so we can fix
them.
Speaking just for Codec Engine and related headers, I know of a few
customers that have called the APIs from C++ code, and we have a few
internal tests
Yep. The memory for the algs was simply malloc()'d.
Chris
-Original Message-
From: T Ziomek [mailto:[EMAIL PROTECTED]
Sent: Monday, January 28, 2008 8:53 AM
To: davinci-linux
Cc: Ring, Chris
Subject: Re: How to make CMEM cacheable on ARM side on DM6446?
. . .
In general
There's a bug in the comments of xdcpaths.mak, have you set REQUIRE_FC
to 0? This statement from xdcpaths.mak is WRONG in CE 2.00:
# If you're not building DSP-side content, you should set REQUIRE_BIOS
to 0 and
# REQUIRE_FC to 0
That's incorrect. Beginning in CE 2.00, in all configurations,
For Q1, perhaps the Codec Engine's Engine_getCpuLoad() might help at a high
level? It's not very precise, but could help with a gross understanding of
how loaded the DSP is.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of Lee Dong Jun
This may help:
http://wiki.davincidsp.com/index.php?title=Debugging_the_DSP_side_of_a_C
E_application_on_DaVinci_using_CCS
Chris
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of kashin Lin
Sent: Wednesday, January 30, 2008 11:55
Some quick feedback - note that Memory_getPhysicalAddress() is _not_ a
supported API. (And in fact has been deprecated in recent releases of
Codec Engine.) I know the demos use it, they shouldn't have been.
Supported APIs are documented in the CE API Reference Guide.
_Instead_, please use the
Check your DSP side codec stack config. If you're right on the edge, enabling
trace may blow it.
Chris
- Original Message -
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
To: davinci-linux-open-source@linux.davincidsp.com
davinci-linux-open-source@linux.davincidsp.com
Sent: Thu Jan 31
Sorry, Ben. I thought someone had answered this.
The short answer is yes, if you're using CE 1.20 or newer. You'll need
to make some small changes to your app .cfg script to use the Link
Arbiter Daemon - some details here:
http://wiki.davincidsp.com/index.php?title=Link_Arbiter_Daemon
So
Please review this thread and see if it answers your question.
http://osdir.com/ml/linux.davinci/2006-09/msg00095.html
In short, your codec package can just have a 64P library, but you may
have to adjust its getlibs() fxn as described at the link above.
Chris
This feature was added in Codec Engine 2.00.
When creating the algorithm, an optional argument string can be
appended to the _name_ of the alg. In CE 2.00, the name can be up to 3
parts separated by a colon ':'. The syntax is name:priority:flag.
The API Reference Guide describes this in a bit
Depending on what and how you want to debug, you can use this:
http://wiki.davincidsp.com/index.php?title=Debugging_the_DSP_side_of_a_C
E_application_on_DaVinci_using_CCS
... and/or if you're using Codec Engine, you can enable the tracing in
that framework.
Good question.
The Framework Components product (used by Codec Engine) remembers the
memTabs returned during the alg initialization - for other things like
scratch sharing - and therefore doesn't need to call algFree().
Note that _other_ frameworks _may not_ store this memTab info
internally, so
Which OS are you on - these library names doesn't look like those shipped with
the Linux-based Codec Engine release; nor do the directory structures match.
Chris
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dinh
Ngoan Nguyen
You should be able to use KDevelop (and any other IDE that supports
building C code with a supported toolchain) to build a Codec Engine app.
There is a 'pre-build' config step required (using the XDC Tools) when
building an executable that will require some extra work.
There are some details on
On DM355 (and other single processor systems, like DM6437), Codec
Engine-based codecs are always configured to be 'local', and as such the
overhead introduced by CE is a function call.
There are other (mostly obvious) Linux-introduced overheads on DM355
like user-mode/kernel-mode context
I don't suspect this to be a Link error as a fork on this thread is
chasing.
More likely, it's a mis-configured server.cfg script. As a simple
example, consider the following:
* codec A and codec B share internal scratch memory
* codec A needs 40k, codec B needs 50k
* codec A and B are
Confirmed, the wiki has the latest, appropriate content on changing
memory maps.
To your other question, I don't think the DVSDK ships with the necessary
components to rebuild the demo servers - specifically because the codec
libraries are required.
I think TI has an avenue through which you can
:[EMAIL PROTECTED]
Sent: Friday, March 14, 2008 12:05 AM
To: Ring, Chris
Cc: Viraj Karandikar;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Error Remote node creation FAILED for
multithreaded application combo server
Sorry
Please post your server build error.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, March 14, 2008 12:46 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: Codec Engine 2.0.1 woes
1 - 100 of 203 matches
Mail list logo
