Forums

Hi Tiger,

The ECU should be fully compatible with the C674x device, provided you are using the C64x+ ECU library and the endian-ness is correct.

How are you packing the PCM samples before sending to the ECU?  Can you attach the code you are using?  Until we see this working properly, it is no use looking anywhere else.

Please pardon me if this is a repeat question, but what do the samples in the delay line look like when you pass in a constant value (e.g., packed PCM zeros = 0xFFFF for u-law and 0x5555 for a-law)?

Regards,
Charlie

Hello.

I am also trying to use the ECU module on the C674x of an OMAP-L138 without any success yet. I am using CCSv5.1.1.

I've checked to be sure the data are given correctly, that is:

void ecuSendIn (void *ecuInst, void *vsend_in, void *vrecv_in, void *vsend_out);

The input vsend_in are PCM linear samples, while the recv_in are a-law samples packed on 8-bits words.

To answer your question about what the delay line looks like, here is the answer.

First, if I look into the "Far-end delay line" buffer, which in my case is 592 bytes, I see correctly packed a-law PCM samples. Using the Memory Browser (Hex 16 Bit), I see the following:

5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555
5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555
5555 5555 5555 5555 5555 5555 5555 5555 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5
D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 55D5 5555 5555 5555 5555 D5D5 D5D5 D5D5 D5D5
D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5 D5D5
[...]

Well, the phone line is silent, so they're all silence patterns. Nothing more to say... BUT, just after the execution of ecuSendIn, if I look into the volatile "Far-end expanded delay line" buffer, it is not what I expected to see. It may be normal, tough, you tell me. Here is what the Memory Browser (16 Bit Signed Integer) gives me:

-8 -5504 -8 -5504 -8 -5504 -8 -5504
-8 -5504 -8 -5504 -8 -5504 -8 -5504
-8 -5504 -8 -5504 -8 -5504 -8 -5504
-8 -5504 -8 -5504 -8 -5504 -8 -5504
[...]

Which is the expansion of 0x55 and 0x00 !!! Is this normal?

Regards,

Jean-Denis

Hi Jean-Denis,

Can you try building and running the unit test project that comes with the delivery?  Detailed directions for ECU unit test (simulation) are linked from the VoLIB User Manual.

Please let me know if this works correctly for you -- I just re-verified that it is working on my end.

Charlie

Hi Charlie.

Yes, it works! I've looked at the resulting sout.pcm and the echo is clean compared to sin.pcm.

Actually, this give me some input to compare with my implementation.

So I'll continue my investigations. More info later...

Thanks for your help.

Jean-Denis

Hi Jean-Denis,

Great!  Let me know if I can help you narrow things down. 

By the way -- did you run on C674x or C64x+?

Charlie

Hi  Charlie,

1. I  test the EUC unit  test project  by CCS  and  the test project can  cancel echo.  It means that ECU can work  in C674.

2. I pack the PCM samoles in the following manner:

    linSample rinLinear[N];
    tint      rinCompr[N];
    tword     rinBuffer[N];
    tint length = N;
    tint i;
   
    /* Compress U-law delay line samples */
    muaTblUlawCmpr (length, rinLinear, rinCompr);

    /* Pack samples for delay line compression */
    for (i=0; i<length; i++) {
      rinBuffer[i] = rinCompr[i] & 0xFF;
    }

3.  I  set all rinBuffer  value to 0xFF.

    The delay line data:

    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124
    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124
    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124
    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124
    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124
    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124

    Why -32124 exist in expand delay line?   I think that the delay line should be all 0.

4.  If  ecu_ENABLE_NLP  is  enabled,   the all soutBuffer  value  is  always  0  whatever   rinBuffer   and sinBuffer  value is. 

5. In ECU test project,  the  PIU  and sgn   is used.  But  is necessary   PIU  and sgn  ???

Hi Charlie,

1.  If   I   add  my own ECU code  to ECU test project   and  CCS  is  used,   and  the ECU  can cancel  echo.  

     But  I  only  use my ECU code in my own project  and CCS  is not used,  ECU  can't  cancel  echo.

     I  use ECU test project code  to my own project   and  CCS  is  not  used,  ECU   can't  also  cancel echo.

Why  ECU  can't  cancel  echo  when CCS  project  in ECU test project  is not used ???

2.  When  ECU can't  cancel  echo, I  set all rinBuffer  value to 0xFF.

    The delay line expand buffer data:

    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124
    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124
    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124
    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124
    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124
    0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124 0 -32124

Why -32124 exist in expand delay line?   I think that the expand delay line should be all 0.

Hi Charlie,

I   new  a  CCS  project  and  add  my  own  ECU code to  the new project.   The  project  can   cancel  echo.

But   the  ECU  can't  cancel  echo  when  I  add the  code  to   EZSDK(5_02_02_60).

Did you test  ECU  in EZSDK  when CCS  is not used ?

I run  AER lib, G.729 lib  in EZSDK  and they  can work  good.     I  get  these  lib  from TI.

Why  my ECU code can  work in CCS  and can't  work  in EZSDK ?

Hi Charlie,

I managed to have the ECU work! And this is a library issue... There seems to be 3 libraries related to the ecu: "ecu_a, ecu_c, ecu_cm". The third one (ecu_cm) should not be present in the link.

When I created the project with CCSv5, and added VoLIB and the ECU, it automatically added the 3 libraries to the file "linker.cmd". If I manually remove "ecu_cm" and re-link, the ecu works!

We all noticed that in the delay line expansion buffer, there was 1 sample out of 2 which was invalid. Then, I used the test case from the ecu library, and injected the exact same data, and the delay line expansion worked correctly. I begun to disassemble the library function "ecu_dline_expand_seg", and it did the job in the test case, but in my program, the disassembly showed a completely different implementation. This function is present in 2 of the 3 libraries, and apparently, it took the wrong one.

So, my question is obvious: "What is the purpose of library "ecu_cm", why does CCS add it in the link, and how can I remove it?"

Regards,

Jean-Denis Boyer

Jean-Denis,

Thank you for delving deep into this and (hopefully) solving the underlying problem. 

The "ecu_cm" library should not be linked in a production build.  This is the "C model" library which we use as a model for creation of  the "a" (assembly code) library.  My guess, before looking, is that the C model code hasn't been updated properly from C55x to C6x.

I will try to recreate this locally and respond to all with my findings.

Regards, Charlie