This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Help getting ECU in VoLIB to work.

Other Parts Discussed in Thread: CCSTUDIO

I am attempting to get the ECU module in the VoLIB to work on 5509A processor.

I have linked the code and can build my test application. Currently I am just trying to see the code

working on the Simulator to prove that it works.

The code seems to be working - with the exception that the echo canceller is not cancelling the echo.

None of the calls are returning errors and calling the ecuGetPerformance function returns

values that seem correct and are changing.

I have allocated all the memory as requested by the ecuGetSizes function and confirmed the correct

size and allignment on the memory blocks I pass into ecuNew.

 

I can build and run the test code in the ECU package and that works correctly, with the echo cancelled.

 

While the code is running, I can see that there is no data being put into the Far-end expanded delay line

and that the Foreground Filter segment coefficients are not updating.

(On the working ECU test  code this buffer is full of data and the FG filter does update).

 

 What things should I check that could be causing the ecu to run, without returning errors or exceptions

without returning any errors.

 

Any pointers or tips would be greatly appreciated.

 

ALSO: Is there any way to disable the delay line compression, as there seems to be no benefit

to using it on a 5509.

 

 

For reference here are some code snippets, showing the relevant ECU structures and calls.

 

/*************************/
/* The ECU Context Setup */
/*************************/

#define ECHO_CANCEL_FRAME_SIZE 40
#define ECU_SEARCH_FILTER_LENGTH         1024
#define ECU_FILTER_SEGMENT_COUNT         3

ecuContext_t ecuContext =
{
    echo_cancel_exception,      /* Exception handler */
    NULL,                       /* Debug streaming function pointer */
    NULL,                       /* MIPS Agent open/close event handler */
    NULL,                       /* Search filter swapping function */
    NULL ,                      /* Send out function pointer */
    NULL,                       /* Receive out function pointer */
    2 * ECHO_CANCEL_FRAME_SIZE, /* Maximum number of samples per frame */
    ECU_SEARCH_FILTER_LENGTH  , /* Maximum filter length in taps */
    ECU_FILTER_SEGMENT_LENGTH,  /* Maximum filter segment buffer length in taps */
    ECU_FILTER_SEGMENT_COUNT,   /* Maximum allowed active filter segments */
    3 * ECHO_CANCEL_FRAME_SIZE, /* Maximum y2x delay in samples */
    0L,                         /* Bitfield representing those portions of the
                                 * delay line already expanded. */
    NULL,                       /* Pointer to base of the scratch delay line */
    NULL,                       /* TDM aligned pointer within scratch delay line */
    NULL,                       /* TDM aligned pointer within packed delay line */
};


/*****************************************/
/* Code to Initialise the Echo canceller */
/*****************************************/

tEchoCancel *echo = &gEchoCancel[echoId];
tint ii ;
tint ecuNumberOfBuffers;
const ecomemBuffer_t *internalMemoryBuffers = NULL;
tint ecuStatus;

ecuStatus = ecuGetSizes (&ecuNumberOfBuffers, &internalMemoryBuffers, (void *)NULL);

if ( ecuStatus == ecu_NOERR )
{
    // Must copy internal buffers before modifying them
    echo->ecuMemoryBuffers = ( ecomemBuffer_t * ) MEM_calloc( SEG_SARAM, sizeof(ecomemBuffer_t) * ecuNumberOfBuffers, 2 );
    for ( ii = 0 ; ii < ecuNumberOfBuffers; ii++ )
    {
         echo->ecuMemoryBuffers[ii] = internalMemoryBuffers[ii] ;

         if ( echo->ecuMemoryBuffers[ii].size > 0 )
         {
             echo->ecuMemoryBuffers[ii].base = (void *)
                 MEM_calloc( SEG_SARAM, echo->ecuMemoryBuffers[ii].size, 1 << echo->ecuMemoryBuffers[ii].log2align );

             if ( echo->ecuMemoryBuffers[ii].base == NULL )
             {
                 ecuStatus = ecu_NOMEMORY ;
                 break;
             }
         }
    }

    if ( ecuStatus == ecu_NOERR )
    {
        ecuNewConfig_t    ecuConfigNew;
        echo->ecuInstance = NULL;

        ecuConfigNew.ID = echoId + 1 ;
        ecuStatus = ecuNew(&echo->ecuInstance, ecuNumberOfBuffers, echo->ecuMemoryBuffers, &ecuConfigNew );
    }
 }



/*************************************/
/* Code to "Open" the echo Canceller */
/*************************************/

configParam.filter_length    = 1024;   // 128 Millisecond tail
configParam.config_bitfield  =  ecu_ENABLE_ECHO_CANCELLER |   /* ENABLE ECU, ENABLE NLP, ENABLE UPDATE */
    ecu_ENABLE_UPDATE            |
    ecu_ENABLE_NLP            |
    ecu_ENABLE_AUTO_UPDATE    |
    ecu_ENABLE_SEARCH         |
    ecu_ENABLE_CNG_ADAPT      |
    ecu_ENABLE_OPNLP_DETECT; ;
configParam.config_bitfield1 = ecu_ENABLE_NLP_PHASE_RND  ;
configParam.noise_level      = 0 ;  /* Use default (-70) if fixed */
configParam.nlp_aggress      = 0 ;   /* Balance Performance */
configParam.cn_config        = 0 ;   /* pink noise */

ecuConfig.samples_per_frame = ECHO_CANCEL_FRAME_SIZE;
ecuConfig.cfgParam          = &configParam;
ecuConfig.sendOutInst       = echo ;
ecuConfig.recOutInst        = echo ;
ecuConfig.y2x_delay         = ECHO_CANCEL_FRAME_SIZE;
ecuConfig.pcm_expand_tbl    = muaTblUlaw;
ecuConfig.pcm_zero          = ULAW_ZERO;

ecuOpen( echo->ecuInstance, &ecuConfig );


/**********************************/
/* Code to use the echo canceller */
/**********************************/

ecuSendIn( echo->ecuInstance,  receiveData, echo->txBuffer, echo->rxBuffer );

 

 

 

 

  • Additional Information: In case this helps...

    VoLIB version is the current one. 1.0.0.1

    I am using CCS 3.3. and my link file looks like this

    -c  /* ROM autoinitialization module */
    -a  /* LINK USING C CONVENTIONS      */

    -l volib\packages\ti\mas\ecu\c55l\ecu_c.a55l
    -l volib\packages\ti\mas\ecu\c55l\ecu_a.a55l
    -l volib\packages\ti\mas\util\c55l\util_c.a55l
    -l volib\packages\ti\mas\util\c55l\util_a.a55l
    -l volib\packages\ti\mas\vpe\c55l\vpe_c.a55l
    -l volib\packages\ti\mas\vpe\c55l\vpe_a.a55l
    -l volib\packages\ti\mas\sdk\c55L\sdk_a.a55L
    -l volib\packages\ti\mas\sdk\c55L\sdk_c.a55L
    -l volib\packages\ti\mas\mhm\c55l\mhm_c.a55l


    /* Use this file just for linking in libraries and setting
    the heap and stack size */
    SECTIONS
    {
      .csldata    > DARAM
      hpimap    > HPIMAP
      GROUP        > VERCONST
      {
          vertag
          version
      }
    }

    volib\packages\ti\mas\ecu\c55l\ecu_cm.a55l
    volib\packages\ti\mas\ecu\c55l\ecu_a.a55l
    volib\packages\ti\mas\util\c55l\util_c.a55l
    volib\packages\ti\mas\util\c55l\util_a.a55l
    volib\packages\ti\mas\vpe\c55l\vpe_c.a55l
    volib\packages\ti\mas\vpe\c55l\vpe_a.a55l
    volib\packages\ti\mas\sdk\c55L\sdk_a.a55L
    volib\packages\ti\mas\sdk\c55L\sdk_c.a55L
    volib\packages\ti\mas\mhm\c55l\mhm_c.a55l

     

    The C Flags / Arguments I am using to build are:

    -g -pdr -pdw -pds195 -fr"$(Proj_dir)\Debug" -i"$(Proj_dir)" -i"$(Proj_dir)\volib\packages" -i"C:\CCStudio_v3.3\C5500\dsplib\include" -i"C:\CCStudio_v3.3\C5500\cgtools\include" -d"_DEBUG" -d"CHIP_5509A" -d"_dsp=1" -d"CC09A" -d"ENABLE_SEARCH" -d"ENABLE_COMPRESS" -d"ENABLE_RELOC" -d"ENABLE_CPD" -d"ENABLE_03DB" -d"ti_targets_C55_large" -mb -ml -v5509A

     

     

     

     

     

  • Hi Paul,

    First off... no, unfortunately you can't disable delay line compression since the ECU is delivered as a compiled object.   However, this should reduce your memory requirements -- even on C55x -- since we pack the PCM data in this case, two samples per word.  Let me know what the call to ecuGetSizes() returns for delay line size (buffer #4).

    To get started -- I have a few questions:

    1. How are you providing PCM data to the ECU (from file, software signal generators, etc.)?
    2. What data are you providing to the ECU? 
    3. Do you have the ability to capture (or store to a file) PCM data at Rin, Sin, Rout and Sout?

    My goal here is to verify the PCM data path from Rin-to-Rout and Sin-to-Sout.  Ideally, if we can capture/store synchronized samples (between Rx and Tx) paths, we should be able to validate the data that the ECU is processing.

    Regards,

    Charlie

  • Hi Charlie,

     

    I did not think it was possible to get rid of the delay line compression .

    And if I look at the buffer while the ecu is running I can see that it is

    full of packed data. The size is 612 words. So that is good anyway.

     

    I have made some progress, my test data has no delay - at the moment I just have

    a very simple copy of the input data attenuated. However I was opening the ecu

    with y2x_delay set to 40 samples (one frame). Once I set the y2x_delay to 0 to match

    my test data things started to work a bit better. The echo is now cancelled, I seem to be losing

    a lot of the far end signal. 7612.testfiles.zip

    I have attached the rin, sin and sout files, converted to 16 bit au format.

     

    The first lot of "far-end" audio gets through the echo canceller, but the second block of audio is

    completely attenuated. So I still have something not working correctly.

     

    Regards

     

    Paul

     

     

     

  • I still am not getting the ECU to work reliably.

    When I use the test project in the ECU everything is Ok. Using the same test samples

     

    Just to confirm: The samples should be fed to and from the ecu in 16 bit linear PCM format.

     

    I am allocating all the memory blocks in SARAM. (See example code above).

    Is this OK / Valid.

     

    I am relying on the sizes provided by the ecuGetSizes call, the test

    code in the ECU module over-writes these values. I assumed this

    would not be necessary. Should I be doing this? 

    Is it OK for all the memory blocks to be in SARAM?

    Here is a print out of the values of size returned by ecuGetSize,

    and the addresses of the blocks I have

    Buffer  0, Base 0x0f324, Size   328 (log2align  1)
    Buffer  1, Base 0x0f570, Size   256 (log2align  1)
    Buffer  2, Base 0x0f670, Size   256 (log2align  1)
    Buffer  3, Base 0x0f770, Size    40 (log2align  0)
    Buffer  4, Base 0x0f798, Size   592 (log2align  0)
    Buffer  5, Base 0x10000, Size  1064 (log2align 11)
    Buffer  6, Base 0x0f9e8, Size  1024 (log2align  1)
    Buffer  7, Base 0x0fde8, Size    14 (log2align  1)
    Buffer  8, Base 0x0fdf8, Size    27 (log2align  0)
    Buffer  9, Base 0x0fe14, Size    27 (log2align  0)
    Buffer 10, Base 0x0fe30, Size     6 (log2align  0)
    Buffer 11, Base 0x0fe38, Size     6 (log2align  0)
    Buffer 14, Base 0x10428, Size  1024 (log2align  1)
    Buffer 15, Base 0x0fe40, Size   256 (log2align  1)
    Buffer 16, Base 0x0ff40, Size   128 (log2align  0)

     

    Any other suggestions for things to check or mistakes I am making would be

    greatly appreciated.

     

    Thanks

    Paul

    I am off to drown my sorrows now...

  • Paul Whitfield said:
    Just to confirm: The samples should be fed to and from the ecu in 16 bit linear PCM format.

    Good question.  When delay line compression is enabled. the "vrecv_in"  (far-end delay line) samples should be passed in as packed PCM:

    buffer[0] = [Sample0 Sample1]  ([15 14 13 .... 2 1 0])
    buffer[1] = [Sample2 Sample3]
    buffer[2] = [Sample4 Sample5]
    ...

     

    This should be described in the integration section of the User's Guide, but unfortunately isn't. 

    Another important point that should be in the integration section (but, again isn't) is the suggested memory buffer placement.  This is of particular importance for the ECU to achieve the stated MIPS performance.  Please see below:

    Buffer SA/DA RAM Type Requirement
    1 SARAM Static Different bank than buffer 5
    2
    SARAM
    Static Different bank than buffers 5 and 6
    5
    DARAM
    Scratch
    None
    6
    SARAM
    Scratch
    Different bank than buffers 2 and 5
    14
    SARAM
    Static
    Different bank than buffers 5 and 6
    STACK
    -
    -
    Different bank than buffer 5

    In addition to the guidelines in the above table, buffers 2, 5, 6 and 14 should not be in the same bank as the object code eculms.obj (.text).

    Additionally, buffers 2 and 5 should not be in the same bank as ecuerm.obj (.text).


    Another suggestion would be to use a simple example, such as the one in the test code, to start off.  I had a look at your example and the noise level appeared to be very high.  This might be a better example to use once all is working and we want to verify ECU performance. 

    I will open a defect report for the deficiencies in documentation.  You can track all VoLIB issues here.

    I hope you have no more need to drown your sorrows -- unless you want to.

    Regards,
    Charlie

  • I successfully drowned my sorrows on Friday night!

     

    When I implemented the packed audio as described, the echo canceller started

    to work. WooHoo!!! I get to keep my job :-)

     

    I have now tested on the target hardware as well and that also seems to work.

     

    Thanks for the information about the memory placement, I will do a bit more functional

    testing and once I am happy all is working correctly I will implement some better memory 

    management as well. 

     

    The manual does contain information about memory buffer placement, however, it seems to differ from what you have given above.

     

    In my application I need to cancel echo on two channels. Can you please verify that it is OK for both echo cancellers

    to use the same scratch buffers?

     

    One other funny I am still seeing is that if I call ecuGetPerformance the values for

    noise_x, noise_y and tail_len don't seem to be updated.

     

    Documentation:

     

    While you are working on the documentation, I noticed that the ecuSendIn call

    could do with more information in the manual. I.e. explain what all the parameters are, not

    just rely on the names of the parameters to know which one is rin and which is sin.

     

    ALSO: table1 ecuContext_t has an extra entry in it that is not actually in the ecuContext_t data structure.

     

     

     

     

     

     

     

     

  • Answer my last problem: I had the wrong format specifiers in my printf, did not realise that the noise values were longs.

    Now have values for X and Y Noise values.

     

  • Paul Whitfield said:

    When I implemented the packed audio as described, the echo canceller started

    to work. WooHoo!!! I get to keep my job :-)

    Excellent, this is great news!

     

    Paul Whitfield said:
    The manual does contain information about memory buffer placement, however, it seems to differ from what you have given above.

    I hadn't realized that ECU.pdf was included in the delivery -- this is a good thing.  The difference between what I posted and what is in the documentation (provided I made no errors) is that I posted the absolute buffer index while the documentation references buffers using indices of buffers in the table.  I believe the post will be easier to follow as the buffer enumerations (i.e., FG_FILTER) are not exposed to the external API.  I will clean this up as part of the same defect report.

     

    Paul Whitfield said:

    In my application I need to cancel echo on two channels. Can you please verify that it is OK for both echo cancellers

    to use the same scratch buffers?

    Yes, scratch buffers can be used in any way once ecuSendIn() completes.

     

    Paul Whitfield said:

    One other funny I am still seeing is that if I call ecuGetPerformance the values for

    noise_x, noise_y and tail_len don't seem to be updated.

    I've read your latest post, glad to see that it's working correctly.

     

    Paul Whitfield said:

    While you are working on the documentation, I noticed that the ecuSendIn call

    could do with more information in the manual. I.e. explain what all the parameters are, not

    just rely on the names of the parameters to know which one is rin and which is sin.

    Yes, good point -- I agree 100%.  This, too, will be completed to close our ECU Documentation defect report. (link).

     

    Paul Whitfield said:
    ALSO: table1 ecuContext_t has an extra entry in it that is not actually in the ecuContext_t data structure.

    Thanks, we'll remove it from the documentation.

     

    Regards,
    Charlie

  • Hi Charlie,

     

    So we now get to the next issue.I have implemented the memory arrangement as described above.

    All the buffers mentioned are not allocated on seperate SARAM pages.

    However, after running for a couple of minutes the DSP stops processing audio.

     

    It looks like somewhere the ecuSendIn function is writing outside its allocated

    memory.  (Commenting out the ecuSendIn function results in the system

    running without crashing for over an hour).

     

    I have allocated two echo cancellers - however up to this point I have

    only tested a single instance.

     

    I have increased the stack for the task calling the ecuSendIn function.

     

    Any suggestions for what I can do to next ?

    Here are the sizes and address I have used ,  I have deliberately made buffer 5 larger

    than required. The rest are the values returned by ecuGetSize

     

    Buffer  0, Base 0x1c000, Size   328 (0148) (log2align  1) Segment 5 Volatile 0
    Buffer  1, Base 0x1f000, Size   256 (0100) (log2align  1) Segment 2 Volatile 0
    Buffer  2, Base 0x1c148, Size   256 (0100) (log2align  1) Segment 5 Volatile 0
    Buffer  3, Base 0x1c248, Size    40 (0028) (log2align  0) Segment 5 Volatile 1
    Buffer  4, Base 0x1c270, Size   592 (0250) (log2align  0) Segment 5 Volatile 0
    Buffer  5, Base 0x05800, Size  2048 (0800) (log2align 11) Segment 1 Volatile 1
    Buffer  6, Base 0x1e000, Size  1024 (0400) (log2align  1) Segment 3 Volatile 1
    Buffer  7, Base 0x1c4c0, Size    14 (000e) (log2align  1) Segment 5 Volatile 0
    Buffer  8, Base 0x1c4d0, Size    27 (001b) (log2align  0) Segment 5 Volatile 0
    Buffer  9, Base 0x1c4ec, Size    27 (001b) (log2align  0) Segment 5 Volatile 0
    Buffer 10, Base 0x1c508, Size     6 (0006) (log2align  0) Segment 5 Volatile 0
    Buffer 11, Base 0x1c510, Size     6 (0006) (log2align  0) Segment 5 Volatile 0
    Buffer 14, Base 0x1d000, Size  1024 (0400) (log2align  1) Segment 4 Volatile 0
    Buffer 15, Base 0x1c518, Size   256 (0100) (log2align  1) Segment 5 Volatile 1
    Buffer 16, Base 0x1c618, Size   128 (0080) (log2align  0) Segment 5 Volatile 0


    Here is part of the map file (the HPIMAP area is used for communications with

    a processor via HPI).


    MEMORY CONFIGURATION

             name            origin    length      used     unused   attr    fill
                            (bytes)   (bytes)    (bytes)   (bytes)
    ----------------------  --------  ---------  --------  --------  ----  --------
    PAGE 0:
      HPIMAP                00000200   00002c00  00002af0  00000110  RWIX
      VECT                  00002e00   00000100  00000100  00000000  RWIX
      VERCONST              00002f00   00000010  00000008  00000008  RWIX
      DARAM                 00002f10   0000d0f0  0000af26  000021ca  RWIX
      SARAM                 00010000   00020000  00013b9b  0000c465  RWIX

    PAGE 1:
      SARAM_P20             00038000   00002000  00002000  00000000  RWIX
      SARAM_P21             0003a000   00002000  00001000  00001000  RWIX
      SARAM_P22             0003c000   00002000  00002000  00000000  RWIX
      SARAM_P23             0003e000   00002000  00002000  00000000  RWIX

    Any suggestions on what to try next ?

     

    I have increased the stack size for the task calling the ecuSendIn to 1024 Units - I have not

    been able to find anywere a stack requirement.

     

    Paul







     

     

  • More Information ... If it helps

    The sendOutFcn and receiveOutFcn function pointers in the ecuContext are both NULL

    Is this valid? Previous I had configured them but they were never called.

     

    The values in my ecuContext are:

    Samples Per Frame = 40

    Max Filter Length = 1024

    Search Filter Length = 1024

    Max Filter Segment Length = 256

    Max Filter Segment Count = 3

    Max y2x delay = 120

     

    The config in my Open are

      configParam.filter_length    = 1024;   // 128 Millisecond tail
      configParam.config_bitfield  =  ecu_ENABLE_ECHO_CANCELLER |
                    ecu_ENABLE_UPDATE         |
                    ecu_ENABLE_NLP            |
                    ecu_ENABLE_AUTO_UPDATE    |
                    ecu_ENABLE_SEARCH         ;
          configParam.config_bitfield1 = ecu_CONFIG_ERL_0DB ;

                configParam.noise_level      = 0 ;  /* Use default (-70) if fixed */
                configParam.nlp_aggress      = 0 ;   /* Balance Performance */
                configParam.cn_config        = 0x7fff ;   /* 0 = pink noise, 0x7fff = white noise, 0x3fff mix of each */

                ecuConfig.samples_per_frame = ECHO_CANCEL_FRAME_SIZE;
                ecuConfig.cfgParam          = &configParam;

    The compiler options I am using are

    Options=-pdr -pdw -pds195 -o2 -fr"$(Proj_dir)\Release" -i"$(Proj_dir)" -i"$(Proj_dir)\volib\packages" -i"C:\CCStudio_v3.3\C5500\dsplib\include" -i"C:\CCStudio_v3.3\C5500\cgtools\include" -d"CHIP_5509A" -d"_dsp=1" -d"CC09A" -d"ENABLE_SEARCH" -d"ENABLE_COMPRESS" -d"ENABLE_RELOC" -d"ENABLE_CPD" -d"ENABLE_03DB" -d"ti_targets_C55_large" -mb -ml -v5509A

    Are these OK? Am I missing any.

    Also I am using an old version of DSP Bios (5.31.02), I don't think that would make any difference since the ECU does not use an DSP Bios functions.

     

    As before... any suggestions greatly appreciated.

    Regards

     

    Paul

     

     

  • Hi Paul,

     

    Nothing jumped out at me regarding your buffer allocation.  It appears to be good regarding sizes and alignment (we can work on placement later).

    Paul Whitfield said:

    The sendOutFcn and receiveOutFcn function pointers in the ecuContext are both NULL

    Is this valid? Previous I had configured them but they were never called.

    These should be NULL.  As you saw, they're no longer used (and will be removed in the future).

    Your configuration and context look valid -- configuration shouldn't cause a crash anyways.

    Paul Whitfield said:

    Also I am using an old version of DSP Bios (5.31.02), I don't think that would make any difference since the ECU does not use an DSP Bios functions.

    Right, the ECU doesn't use BIOS in any manner.

    You might try to narrow down where the problem stems from.  I would test each of the following configurations for crash:

    1. Disable ECU (no ecu_ENABLE_ECHO_CANCELLER)
    2. Enable ECU, disable search (ecu_ENABLE_ECHO_CANCELLER, no ecu_ENABLE_SEARCH)
    3. Enable ECU, disable search, disable adaptation (ecu_ENABLE_ECHO_CANCELLER, no ecu_ENABLE_SEARCH, no ecu_ENABLE_UPDATE

    Depending on what we see here, we can simplify the problem and focus in on the culprit.

    I'll keep you posted if anything else comes to mind.

    Regards,
    Charlie

     

  • Hi Charlie,

    I though I had got the memory  placement correct as per your previous posts....

    If I disable everything. The firmware runs correctly working for several hours.

    If I just enable ecu_ENABLE_SEARCH the code stops working after a few minutes (about the same as before).

    The sympton is that I stop getting transmitted / received audio via the McBSP driver. The DSP code

    is still running, but the audio as stopped working.

    Just to make sure this is not a stack problem I have made all the stacks much bigger,

    Task stack = 1024 MDU, System stack = 1024.

     

    Regards

     

    Paul

     

     

     

  • Hi Charlie,

     

    Just to let you know I finally got to the bottom of my problem and it was stack related.

    (I did not make the HWI stack big enough).

     

    So I am back on track with the testing of the echo canceller with a real system.

    One more question: There is an option in the ECU control code that is

    Enable/Disable demeaning of the search filter...

     

    I have to ask ... what is the meaning of demeaning... (this is actually a serious question).

    P.

  • The saga continues:

     

    I now have the ecu code running happily without crashing.

    If I enable the NLP it is working pretty well, when I have no double talk the echo is completely gone.

    However, it seems like the adaptive filtering part is not working at all.???

     

    I have compared my code with the example code /test code in the ecu and I think I have everything set up correctly.

    I have done these test using the same input files - generated by the ecu test code and then saved to a file. 

    The ecu test code works, the filter "tunes in" and all is good.

    On my test code the filter is not working.It does not crash, but the echo is not cancelled.

     

    I have checked: values in ecuContext, values in structures passed to ecuNew and the values in structure passed to ecuOpen

    I am passing to ecuSendIn in blocks of 40 samples:

    ecuInst = void pointer ecuInstance returned by ecuNew

    vsend_in = 40 samples, 16-bit linear data,  near end received data

    vrecv_in = 40 samples, packed u-Law audio, near end transmitted data

    vsend_out = buffer for 40 samples, 16-bit linear data. Should be echo removed.

     

    The settings I am using are:

    Filter length = 1024

    Frame Size = 40

    Config Mode0 =  ecu_ENABLE_ECHO_CANCELLER | ecu_ENABLE_AUTO_UPDATE | ecu_ENABLE_UPDATE | ecu_ENABLE_SEARCH;  (this is 0x53)

    Config Mode 1 = 0 ;

     

    The test code even word aligns the buffer used for returning the echo cancelled data. Is this required?

     

    I am using filter segment lengths of 256 and 3 segments. This is copied from the ECU test code,

    are  these reasonable values?

     

    What can you suggest that I try next?

     

     

     

     

     

     

     

     

     

  • Hi Paul,

    I'm sorry to leave you hanging - Charlie is on vacation, but I've referred your information to another echo canceller specialist, and will get back to as soon as possible.

    John

  • Hi John,

    Thank you for the update.

    I have successfully resolved all my issues.

    In summary for future reference the major issues that caused my problems

     

    1. There is no "quick start" guide on how to use the VoLIB components, initially I

    got the impression that CCS V4 was required to use the components. However

    in the end I was able to use the files with CCS V3 successfully.

     

    2. Problems with the documentation, a believe a bug report has been raised to cover this.

    The main issue here was that it was unclear what format the data fed into the algorithm

    needed to be. I.e. the data must be in a packed companded format.

     

    3. I incorrectly packed my companded  transmitted data before I fed it into the algorithm, it was close

    enough that it took me a while to realise my mistake. The NLP part of the algorithm was

    working, despite this, making it confusing to debug.

     

    4. The ECU was using more stack than I had allocated. It appear to require 512 words of stack. 

    It would be desirable to have the stack requirements as part of the documentation.

     

    Issues 3 & 4 were my implementation mistakes.

    With all these mistakes fixed, the ECU now seems to be working correctly.

     

    We are currently testing it in the final product.

     

    PS: i hope Charlie has a good vacation.!

  • Hi Paul,

    Thanks for the update, I'm glad to hear everything is resolved.  Your observations will help us improve the documentation.

    John

  • Hi  Paul,

    I am  also  attempting to get the ECU module in the VoLIB to work on C6A8168 processor.

    The code seems to be working - with the exception that the echo canceller is not cancelling the echo.

    You refer to buffer placement in ECU.pdf.  In my code, I  haven't  place the buffer  in diffrent  segment  or bank.

    All MEM_calloc()  first  parameter  'segid' is set to 0. 

    I have a few questions:

        1.  Can buffer placement  effect the echo canceller ?

        2.  I don't use  CCS in my project.  How  to place the buffer in diffrent  segment or bank ?

    Thanks in advance,

    Gloden

  • Hi Gloden,

    I wouldn't worry too much (just yet) about the buffer placement strategy.  This serves to ensure optimal MIPS performance -- once the ECU is working properly.

    I have two quick questions:

    1.  Are you packing the PCM samples before passing to the delay line?
    2.  What are you using for your echo path model?

    If the answer to (1) is "no", then please refer to the following post:  RE: Help getting ECU in VoLIB to work.  In this post I describe how to pack the PCM samples that the ECU expects to receive (also, if the answer is "no" I see that we need to better document this).

    Please let me know how things proceed.

    Regards,
    Charlie

     

     

  • Dear all,

    I  see the BG  filter coefficients  can be updated  but  FG  filter coefficients  is 0.

    It  is possible that  rinBuffer(TX path)   data  don't  be  stored  in Far-end delay  buffer  and  Far-end expanded delay  line buffer.

    It  is also  possible that  data in Far-end delay  buffer  and  Far-end expanded delay  line buffer    is   incorrect.

    After  ecuSendIn( ) is called,  I print  the  data in  Far-end delay  buffer  and Far-end expanded delay  line buffer. 

    I found the data  in Far-end expanded delay  line buffer is strange.

      The data:  u-law, 40 samples per frame

    ......

    Far-end delay  buffer:

    255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255
    255 255 255 255 255 255 255 255 255 255 255 169 155 148 144 144 147 154 167 219

    Far-end expanded delay  line buffe:

     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 5628 -32124 10364 -32124 13948 -32124 15996 -32124 15996 -32124 14460 -32124 10876 -32124

    .....

    Far-end delay  buffer:

    43 28 20 16 15 19 25 37 77 173 156 149 144 143 146 153 164 197 47 29
    21 16 15 18 24 34 62 179 158 150 145 143 145 151 160 186 55 31 23 17

    Far-end expanded delay  line buffer:

     -4092 -32124 -9340 -32124 -13436 -32124 -15996 -32124 -16764 -32124 -14972 -32124 -11900 -32124 -7420 -32124 -2108 -32124 3516 -32124
     8828 -32124 12924 -32124 15484 -32124 16764 -32124 15484 -32124 12412 -32124 7932 -32124 2620 -32124 -3004 -32124 -8316 -32124

    ......

    I  found that  -32124  in a couple data.  "-32124"  stands  0 in u-law format. 

    Whether  the data is wrong  in Far-end expanded delay  line buffer ?

        

  • Hi Tiger,

    Please see my response in this thread.  This should fix the problem you are seeing.

    Regards,
    Charlie