Why is codec engine load so slow?

What device are you on?

Note that TraceUtil_start() calls Engine_open() under the covers, which can load the DSP.  Can you reproduce this with just Engine_open() (without TraceUtil) to simplify things? 

When enabling CE_DEBUG, timestamps are dropped.  Can you narrow down where in call flow the bulk of time is spent?  (Another note - CE_DEBUG and TraceUtil are mutually exclusive... another reason to reproduce this without TraceUtil.)

If we find, as I suspect, the time is spent in loading the DSP, where is the DSP image physically being loaded from?  If the DSP image is on a slow file system or on the network, the initial load might involve file system mounting or driver initialization to make the slave image visible.

Chris

Hello, and thanks for helping, Chris.

1) I inherited use of TraceUtil_start() from the dm6467 demo encodedecode, so I haven't coded software for Engine_open() without TraceUtil_start(), although I have coded software for Engine_open() in other threads after TraceUtil_start().

2) Things have gone all "wonky".  It appears you CAN turn on CE_DEBUG while using TraceUtil_start().  You just get a message that TraceUtil will be disabled.  When I do this (set CE_DEBUG=3), however, with no changes whatsoever to my application, I get a segmentation fault in unrelated code after the TraceUtil_start() has returned.  This code *should* be bug free.  I've checked, and it's not a different thread causing the problem, so this makes no sense at all.  Also, the TraceUtil_start() returns after 3 seconds rather than 60 seconds, so it's not actually loading the engine.  I run my other script that does unset CE_DEBUG, and the same application works.  In fact, it takes 60 seconds the first time, and only a few thereafter.  (Note that's another clue, all along it has been the first run after boot that takes 60 seconds, not subsequent runs.)

3) Rather than chasing the segmentation fault, which is probably a red herring, I tried to actually replace the TraceUtil_start() call with a direct Engine_open() call.  When I do this, I still get wonky behavior.  I can recompile back and forth between the two methods, and TraceUtil_start() works while Engine_open() doesn't.  This is all WITHOUT CE_DEBUG set.  Again, the program dies later during the same process, but without the "segmentation fault" message coming out.  It seems that doing *EITHER* the CE_DEBUG=3 *OR* using Engine_start() instead of TraceUtil_start() leads to my program dying in that later code, when that later code *should* be fine and I'm not chasing that red herring.

Perhaps I'm not doing Engine_open() correctly.  In order to switch back and forth between the two methods, ALL that I'm doing is changing between "#if 1" and "#if 0" in the code below.  Is there anything else I need to do?  In both cases, they are long ago preceded by CERuntime_init().  (Forum won't keep my indentation...)

#if 0
        /* Initialize the logs. Must be done after CERuntime_init() */
        DBGMIN("DBGMIN: TraceUtil_start codec engine %s\n", engine->engineName);
        TraceUtil_start(engine->engineName);
#else
        DBGMIN("DBGMIN: MAIN: OPEN CODEC ENGINE %s\n", engine->engineName);
        hEngine = Engine_open(engine->engineName, NULL, NULL);
        if (hEngine == NULL) {
                ERR("Failed to open codec engine %s\n", engine->engineName);
                cleanup(SECTION_FAILURE);
        }
#endif
        DBGMIN("DBGMIN: Codec engine started %s\n", engine->engineName);

What device are you on?  And what version of Codec Engine?

TraceUtil is only supported in CE 2.x (although unfortunately untested libraries are currently shipped with CE 3.x - that's getting fixed in a future CE 3.x release).  We really don't encourage TraceUtil usage anymore.

[ I'm going to move this to the Linux forum (which I/we also monitor) as it's more a Linux question than a codec question. ]

Chris

DM6467.  Codec engine 2 25 01 05.

RESOLVED.

1) I fixed my unrelated buffer overflow (red herring), and then I could move past.

2) It appears that MERELY replacing TraceUtil_start() with Engine_open() sped up my codec load from 60 seconds to ... roughly 3 seconds

My power-on to app running time was 2:17 (minutes:seconds).  Now it has improved to... 1:26 (minutes:seconds), a 51 second improvement.  Actual codec load itself took 55.661 seconds using TraceUtil_start() and only 00000000000.881 using Engine_start().  So TraceUtil itself was costing me almost 55 seconds.  (4 second diff in 51 vs 55 due to other causes about which I don't care right now.)

It seems to me that the big time delay was the setup for TraceUtil itself.  By removing it, things sped updramatically...

Chris, please do the following:  Post a reply below here that BEGINS with comment like "TraceUtil setup is costing you that minute.  Use Engine_start() directly rather than TraceUtil_start(), and your codec load will speed up dramatically."  Then I'll mark THAT as answer, so you get computerized credit for assistance as well.

Overall, note that demos have TraceUtil_start() in them.  Perhaps that should be changed or at least commented very well!

Now my remaining big delays are:

1) 25.6 second delay before "VFS: Mounted root (jffs2 filesystem) on device 31:3."  Should I use a DIFFERENT file system in my NAND (same brand as DM6467 EVM).

2) 11+ second delay after "Starting udev".  Note in past it was over 25 sec, and most recent missing "Populating dev cache".  Regardless, should I change to mknod and not use udev?  I don't know how to do this.

I've already posted about these at http://e2e.ti.com/support/embedded/linux/f/354/t/92491.aspx#634195, but haven't gotten to a resolution yet...

Thanks very much for your help on this codec load, Chris.