engine close error!

Can you set CE_DEBUG=2 and get any further details that lead up to this assert?  That particular assert appears to be a failure to receive a message from the DSP - just looking for more hints as to what went wrong.

Might also help if you attach to the DSP with CCS and see if it's doing what you expect.

Chris

hi,Chris

I can't set CE_DEBUG=2 and get details message for that because have intergrated the engine interface to a module,

But The reason why lead to this result is I was using a g729 speech concurrent and crashed randomly by engine colse...

Benlu,

Do you mean you have written some wrappers around the Engine interface?  I'm not sure why this would prevent you from using the CE_DEBUG environment variable.

Where are you calling CERuntime_init()?  That's where the CE_DEBUG environment variable is read, and the appropriate trace masks are set according to the value of CE_DEBUG.  If you really can't use CE_DEBUG, you can look at the code in CERuntime_init(), which is located in ti/sdo/ce/CERuntime.xdt, to see how to set trace masks. Basically, you will have to include the file:

    #include <xdc/runtime/Diags.h>

and set trace as follows:

    xdc_runtime_Diags_setMask("ti.sdo.ce.%+EX1234567");
    xdc_runtime_Diags_setMask("ti.sdo.fc.%+67");

    xdc_runtime_Diags_setMask("ti.sdo.ce.osal.%-EX123");

Some modules such as ti.sdo.ce.osal emit excessive trace that can clutter the output, and the last line above will eliminate the unnecessary output from osal.

Also, just to clarify, are you simultaneously creating a codec and closing an engine when the assertion in Engine_createNode2() is firing?

Best regards,

    Janet

Yeah, I have written some wrappers around the Engine interface in a g729 speech application. I supperated Engine APIs from SPEECH1 APIs, and Engine APIs initalize in my working system, working system call APP API which warappered by  SPEECH1 API. 

I don't know the reason why lead to this result?

Also, I set CE_DEBUG, but when concurrent g729 speech ,my working system crashed randomly.

Benlu,

Could this be a threading issue?  Are you accessing the same Engine handle from multiple threads?  Here is some documentation on Engine_open():

 *  Engine handles must not be concurrently accessed by multiple threads; each
 *  thread must either obtain its own handle (via Engine_open()) or explicitly
 *  serialize access to a shared handle.

Best regards,

    Janet

When I create a g729 thread, I locked it to prevent from accessed concurently... 

Ok, good to see you're using a lock around the Engine handle.  It still looks like there is a concurrency issue, as your first post indicates that the assertion in Engine_createNode2() is occurring while you're calling Engine_close().  How many of these threads are running when the crash occurs?  Any trace output would really be helpful in trying to solve this issue.

Best regards,

    Janet

I couldn't count how many of these threads are running when the crash occurs because system crash randomly. There wasn't any output message for that only the assertion Engine_createNode2() is ocurring...

Janet,

You are familiar with codec engine, what you said is true. It's Comm_get() failing, I used to insmod syslink default and I will try to enable syslink trace.

Certainly, my versions of codec engine is 3.21.00.19. 

Benlu,

I noticed that this thread has been marked as answered.  Were you able to solve the Engine_createNode2() assertion when you have multiple threads?  The post that has been marked as verified just tells how to turn on SysLink trace, which doesn't indicate that your problem was really solved.  I'm just wondering, in case there is an issue with Codec Engine or SysLink.

Best regards,

    Janet

Janet,

I turn on SysLink trace a few days ago, and my mates traced the assertion period of time,but still not any progress for that. So we try to open another temporary solution, because we don't have much time to figure out the reason why the assertion occured.

We created handles before using it, and place them in array. While occuring a concurrent calls, a idle handle will be token out from the array, the handle status will be restored when call end. Maybe it will occupy many resources, but it's the best solution given as fastly as we can.

I will back to trace and figure out why this assertion occured if I have enough time to trace.

Thanks