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.

TMS320C5535: AER/AEC Default Parameters

Part Number: TMS320C5535

Hello,

we connected two ezdsp5535 boards via i2s and built two intercom units with a microphone and a speaker on each side. On software side we use i2s and dma to loop through the data. As example we hatd the beam form and usb audio demo code. We can talk in both directions and sound is good. Second step was to integrate aer/aec library. We did this similiary as in the aer demo code. Software runs, but audio is scrambled in one direction. We didn't execute quick tuning yet.

Questions:

- After opening aer instance, all parameters must be set explicitly through aerControl. Is this correct? When we don't call aerControl at all or leave out some values in the aerControl_s struct, we get an error.

- Do you have a set of default parameters with which we can start? At the moment we use the parameters from the aer demo application.

- When algorithms are turmed off, sound is good in both directions. When algos are active, sound is scrambled in one direction. Is this due to the fact that we didn't execute quick tuning yet?

- Reading back parameters from aer instance is not possible, right? So we must remember parameters externally.

Thanks in advance

Marc

  • Hi Marc,

    The team is notified. They will post their feedback directly here but could you give more details about the issue?
    Which example you follow?
    Could you specify the error which you got?

    BR
    Tsvetolin Shulev
  • Hello,
    we coded our application similiar to the BF_rt_bios demo (beam form for evm5517). Instead of using beam form algorithm, we use aer. There is only 1 mic instance. We only use AER, no AGC, no DRC or any other algos.

    Init procedure:

    aerCreate()
    aerGetSizes()
    aerNew()
    aerOpen()
    aerControl()

    Runtime Calls:

    aerSendIn()
    aerReceiveIn()


    We wanted to work with default parameters at first, so we left out the call to aerControl(). Then aerSendIn() and aerReceiveIn() returned
    aer_ERR_NOINITGAIN -> tx/rx initial analog gains not set . Then we added aerControl() call and initialized the values mentioned in api documentation (tail_length, eq_params, cng_rx_level, cng_tx_level,  txfdnlp_msec_delay, txfdnlp_cng_max, y2x_delay, tx_slim_mode, rx_slim_mode plus tx/rx analog gains). Then aerControl() returned aer_ERR_INVALIDPAR -> configuration parameter is invalid. After that we initialized all parameters in the aerControl_s struct. Then aer could be initialized and runs without errors. But sound is scrambled in one direction. The other direction sound is good. This must be caused by the aer algos. When we just copy the buffers and don't call algos, the sound is fine in both directions. We just copied the parameters from aertest_c55l_C55L_COFF demo. But we don't know if these can be used as starting point for quick tuning. Perhaps scrambling is due to false parameters?


    Questions:

    1. why is sound scrambled in one direction?
    2. do you have a aerControl_s parameter set with which we can start quick tuning (default parameters)?


    Thanks so far

    Marc

  • Hi Marc,

    Please see my answers below. 

    Questions:

    - After opening aer instance, all parameters must be set explicitly through aerControl. Is this correct? When we don't call aerControl at all or leave out some values in the aerControl_s struct, we get an error.

    AER has several system parameters that must be set when you calll aerOpen(). The rest of parameters need to be set by aerControl(). If you don't call aerControl(), these parameters will use the default value. However, AER is turned off by default, so you'll have to at least turn on (enable) AER through aerControl(). Examples of using aerControl() can be found at: packages\ti\mas\aer\test\aersim\aersim_setup.c. 

    - Do you have a set of default parameters with which we can start? At the moment we use the parameters from the aer demo application.

    Default values of AER parameters are documented in aer.h, except the system parameters set by aerOpen(). The system parameters have no default values and must be set by the user. 

    - When algorithms are turmed off, sound is good in both directions. When algos are active, sound is scrambled in one direction. Is this due to the fact that we didn't execute quick tuning yet?

    Did you mean turning on AER by "When algos are active"? Yes, AER must be tuned in order to work properly. The very minimum tuning is documented in docs\AER_Quick_Tuning_Guide.pdf. If you don't care much about the speaker volume, you can jump to chapter 5 to verify AER convergence. Without first converging, AER won't work properly.

    - Reading back parameters from aer instance is not possible, right? So we must remember parameters externally.

    Correct, there is no API to read back all parameters, but you can read the key parameters through structure aerDebugStat_t and function aerGetPerformance().

    - why is sound scrambled in one direction?

    Most likely it is because AER is not converged. 

    - do you have a aerControl_s parameter set with which we can start quick tuning (default parameters)?

    Please refer to answer above. 

     

    Regards,

    Jianzhong

  • Hello,

    thanks for your answer!

    According to your answer:

    "AER has several system parameters that must be set when you calll aerOpen(). The rest of parameters need to be set by aerControl(). If you don't call aerControl(), these parameters will use the default value. However, AER is turned off by default, so you'll have to at least turn on (enable) AER through aerControl(). Examples of using aerControl() can be found at: packages\ti\mas\aer\test\aersim\aersim_setup.c. "

     

    - Not calling aerControl() and using default parameters doesn't work. This leads to an error when calling aerSendIn() and aerReceiveIn().

    - Just enabling AER in aerControl_s struct also doesn't work. This leads to an error in aerControl() call..

    aer_create_cfg.config_bitfield = 0x0;
    aer_create_cfg.debugInfo = NULL; // todo: set callback
    aer_create_cfg.eventOut = NULL; // todo: set callback
    aer_create_cfg.max_sampling_rate = aer_SRATE_16K;

    err_code = aerCreate(&aer_create_cfg);

    aer_size_cfg.max_tail_length = AER_SIM_HF_MAX_FILT_LENGTH;
    aer_size_cfg.max_y2x_delay = AER_SIM_HF_MAX_Y2X_DELAY;
    aer_size_cfg.config_bitfield = aer_SIZE_FDNLP_REQ; /* use FDNLP for HF */

    err_code = aerGetSizes(&num_bufs_req_by_aer, &bufs_req_by_aer,&aer_size_cfg);

    aer_new_cfg.handle = NULL; // todo: id which is passed to dbg and event callbacks -> see aer_create_cfg
    //aer_new_cfg.handle = (void *) siuMakeID(
    // (SIU_MID_AER | AER_HF0_ID), 0);
    aer_new_cfg.sizeCfg = aer_size_cfg;
    *inst = NULL;
    err_code = aerNew(inst, num_bufs_req_by_aer, bufs_aloc_by_siu,&aer_new_cfg);

    aerCfg.y2x_delay = AER_SIM_HF_MAX_Y2X_DELAY / 2;
    aerCfg.srate_bitfield = aer_SRATE_RXIN_16K | aer_SRATE_TXOUT_16K
    | aer_SRATE_RXOUT_TXIN_16K;
    aerCfg.tail_length = AER_SIM_HF_MAX_FILT_LENGTH / 2;
    aerCfg.delay_tx_ag_chg = 160; // für agc adaption
    aerCfg.delay_rx_ag_chg = 160; // für agc adaption
    aerCfg.num_samp_interp = 1; // für agc adaption
    aerCfg.phone_mode = aer_PHM_HF;
    aerCfg.reset_bitfield = aer_RESET_FULL;
    aerCfg.valid_bitfield = aer_CFG_VALID_BITS_ALL_1;

    err_code = aerOpen(inst, &aerCfg);

    /* valid bitfield 0 */
    aer_ctl.valid_bitfield_0 = aer_CTL_VALID0_MODES_CTL0;
    aer_ctl.modes_0.mask = aer_CTL0_ENABLE_ECHO_CANCELLER;
    aer_ctl.modes_0.value = aer_CTL0_ENABLE_ECHO_CANCELLER;

    aerError = aerControl(inst, &aer_ctl);

    Error when calling aerControl() with error code 5!

     

    So it seems that we need to supply all parameters in aerControl_s struct during initialization time?! Leaving out some parameters leads to an error.

     

    Thanks Marc

  • Hello,

    I am trying to measure convergence as mentioned in chapter 5 of quick tuning guide. . For this purpose I output the coherence_state, max_canc_l2 and curr_canc_l2 in aerDebugStat_s. Now I want to measure the signal as shown in Figure 5 on page 12. At which point at the near or far end do you measure the signal? Is it an analogue or digital signal?

    Since we are working with the ezDsp5535 board, we cannot use the rtp send tool to send audio data to the dut. I am thinking of using the provided usb audio demo, e.g. playing the audio file on the pc and sending it to one ezDsp5535 board via usb. From there send the data via i2s to the far end side (dut). My question now is whether i can do this for 4.3.1 Determining Receive Path Gains for Nominal Volume. I think for this step the volume of the injected audio data must be known. When I send it via USB, the volume is changed via the volume slider on pc side. Is it important to transfer the audio data without volume change to the dut? Another idea is transfer the data to the dut memory via debugger play it from there. Whats the best way to inject audio data?

    Thanks so far and have a nice day

    Marc
  • Hello,
    I am looking at the sample pcm files in the aer/tools/signals folder. Do these files contain stereo or mono sample data? Is it necessary to transfer the complete files to the target, or is a small area with sound sufficcient which can be played repeatedly? I am thinking of loading the data into free RAM buffers and play it from here. But max. 64k bytes are available in target RAM.

    Thanks so far

    Marc
  • Hello,

    nothing new in here? Is it possible to inject the pcm test files with the help of the csl usb audio demo and a ezdsp5535 board? I mean just sending the files from pc via usb to a ezdsp5535 board and connect the i2s output to the i2s inputof the dut (receive data from far end)? And also the other way round, connect the i2s output of the dut (send data to far end) to the i2s input of the board and send the data to the pc via usb. Is this principally possible? Is the data manipulated within the usb audio demo (volume changed, sample rate converted,...)? Are there any defines which must be set in usb audio demo to achieve this?

    Thanks in advance

    Marc

  • Marc,

    Sorry for my late response here. Let me try to answer your questions one by one.

    1. Regarding the error you got when calling aerControl(), if you only change parameters in valid_bitfield_0, you'll need to set other valid bitfields (_1, _2, _3, _4) to 0 explicitly. 

    2. Regarding question: " Now I want to measure the signal as shown in Figure 5 on page 12. At which point at the near or far end do you measure the signal? Is it an analogue or digital signal?". It should be digitally captured at the output of send path, with NLP disabled. 

    3. Regarding questions "Is it important to transfer the audio data without volume change to the dut?". No, it doesn't matter if volume is changed on PC. As long as the gain between receive path output and send path input doesn't change during convergence, you're fine. 

    4. Regarding how to inject audio data, what you described below is a good approach: "playing the audio file on the pc and sending it to one ezDsp5535 board via usb. From there send the data via i2s to the far end side (dut)." 

    Hope this can clarify and help.

    Regards,

    Jianzhong

  • Hi,

    thanks for your answers.

    According to your answer:

    4. Regarding how to inject audio data, what you described below is a good approach: "playing the audio file on the pc and sending it to one ezDsp5535 board via usb. From there send the data via i2s to the far end side (dut)."

    I think for quick tuning step "4.3.1 Determining Receive Path Gains for Nominal Volume", the amplitudes of the injected i2s signal must be known. Otherwise the calibrated gain values are not correct. So when we send the pcm file to the target, amplitudes are possibly changed by windows according to the volume slider. When receiving the data with "C55x Connected Audio Framework" and injecting the i2s data to the dut, the gains should be adjusted to achieve 70dBSPL output level. But this only makes sense when knowing the amplitudes of the injected i2s signal?! Am i wrong here?!

    So I think it is better to send/receive the audio data via raw usb tranfers and not via "C55x Connected Audio Framework". There are some examples for USB CSL. For some examples the USB Host tool (WinUsbTest.exe) is needed. From where can I get this tool?

    Thanks in advance

    Marc

     

     

  • Hi Marc,

    You're right. However, I'm not an expert in USB Host tool. 

    Regarding gain calibration, unless your product has to meet some standard specification (e.g. TIA-810 for IP phones), you can start with 0dB AER digital gain and a nominal DAC gain (e.g. 6dB or 12dB down from max). See if you have comfortable loudness. Also, try to do this in a setup that is closest to your final product. 

    Regards,

    Jianzhong

  • Hi Jianzhong,
    thanks for your answer. We do not have to meet standard specs. Some additional questions from me:

    1. What do you mean by 6 or 12 dB down from max? You mean DAC max. gain minus 6 or 12 dB?
    2. What about send path gains? What are good values to start with, without adjusting gains exactly?
    3. In CSL USB examples documentation USB Host tool is mentioned several times. It should be requested from TI and it can be used to test USB communication with device. Any idea from where we can get it? I couldn't find any download link.

    Thanks in advance

    Marc
  • Marc,

    Please see my answers below:

    1. What do you mean by 6 or 12 dB down from max? You mean DAC max. gain minus 6 or 12 dB?

    Yes, that's correct. Usually you don't want to use max DAC gain to avoid speaker distortion at high volume. 6dB margin should be enough for speakers with reasonably good quality. 

    2. What about send path gains? What are good values to start with, without adjusting gains exactly?

    Same rule of thumb as receive path gain. 

    3. In CSL USB examples documentation USB Host tool is mentioned several times. It should be requested from TI and it can be used to test USB communication with device. Any idea from where we can get it? I couldn't find any download link.

    I'm not an expert in this area, so let me ask other people to help out. 

    Regards,

    Jianzhong

  • Hi Jianzhong,

    just one additional question concerning AER/AEC library. I read that when transferring data to/from i2s via dma, the words are swapped. Is that right? Do we need to swap the words back before feeding the data into aer/aec library? At the moment we just give the i2sdmaread/write buffers to the aer algorithms without swapping. Is this ok?

    From software side we have a framework to tune and test aer/aec. Now we are waiting for the final hardware setup. As soon as this is available, we come back to you if there are any issues concerning tuning of aer parameters.

    Thanks so far

    Marc
  • Hi Marc,

    I'm not sure about data swapping of I2S and DMA, but if the words are swapped, you'll need to swap back before sending the data to AER. AER must be provided with linear and continuous data. 

    Regards,

    Jianzhong