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.

AM5728: Echo cancellation using VOLIB in DSP

Part Number: AM5728

Hello,

We are working on a customized board based on AM5728. We want to implement echo cancellation using DSP cores. We are working on ARM linux on A15 core. We have downloaded Volib provided on TI website for same.

Following are the queries regarding the same:

1) We can run Volib ECU example on DSP using CCS and Jtag emulator. How can we run the ECU example from A15(arm linux) core without using emulator?

2) When we run the ECU example from CCS on DSP using Jtag emulator, the output pcm files are saved on host PC. Where will they be created if the ecu example is run from A15 core?

3) In our implementation we want to send the RTP packets received on A15 core to DSP for processing, and then send the processed packet back to A15 core from DSP.  How can we implement the feature? Can we implement this using IPC?

4) How to implement an application on A15 core(arm linux)  which can offload ECU on DSP and do packet processing?

5) There are external API's provided in Volib, can we call the API's from a application written for A15 core? How can we integrate Volib with the Linux SDK?

Regards

Akshi

  • Hi Akshi,

    I am not familiar with Volib myself, can you point me to the appropriate references?

    Have you looked through the various IPC documentation provided in the SDK?

    regards

    Suman

  • Hi Akshi,

    Thanks for the Volib references. Here are some initial responses to your questions.

    1. The DSPs are loaded and booted by the OMAP remoteproc driver by ARM Linux Kernel. AM5728 DSPs have MMUs (2 MMUs), and one chief difference between a standalone CCS and Linux is that Linux always uses/enables these MMUs. This is done through a ".resource_table" section in the ELF firmware file. So, you would need to add one to your firmware image to begin with to allow the OMAP remoteproc driver to load and boot. You would also need to reserve a DDR memory region in the board dts files. You are primarily looking at RSC_CARVEOUT and RSC_DEVMEM resource types.

    2. Hmm, how is this achieved currently? The firmware itself is running on the target and your firmware will not have access to your host PC, so who is doing the saving? You have to have an entity transfer the data from memory to the host PC, who is doing it?

    3. How big are your packets? The Linux-DSP IPC on AM57xx uses a transport called virtio-ring. This is a processor-copy based transport, and the maximum payload for these packets is 496 bytes. You can always use a separate reserved memory carveout, and send pointers to it instead in your message. But this depends on your packet size, frequency of transfer and whether you want in-place processing of buffer.

    4. You have to use the IPC 3.x API/stack on both sides to be able to write an application that exchanges messages with DSP. The standard interface used is the TI MessageQ API.

    5. Do you need the exact same API to be exposed on the Linux-side as well, or you can do with a subset partitioning of functionality? The traditional model is to do a client-server model with the client on Linux-side and the server of DSP-side. There are couple of different ways of achieving this.

    regards

    Suman