• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 940 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

VoLIB Multichannel Memory Usage and Specific Module Implementations

Chris Johnson1
Expert 1715 points
Other Parts Discussed in Thread: SYSBIOS

Hello,

I am using several modules from VoLIB 2.1.0.1 in a voice processing path on a C6678. I'm running multiple channels for each core. I'm currently using TDU, TGE, ECU, and VAU. I have some questions regarding memory usage between each channel and some of the options for each module:

TDU:
1. What is the difference between the Lite and Full implementations? I don't see any references to these in the VoLIB documentation other than the memory requirements.

2. The memory requirements show that buffer 1 is a scratch buffer. Is there any way to know from the code which buffers are scratch and which are dedicated? Can it be assumed that the second buffer is always scratch and the other buffers are always dedicated?

3.  This post (http://e2e.ti.com/support/embedded/tirtos/f/355/t/230652.aspx) seems to suggest that there's a problem with CPT when sharing the scratch buffer, but I'm only using the TDU module for DTMF. My understanding is that the dedicated buffers will need to be allocated for each channel, but the scratch buffer can be shared between channels, but the buffers are listed as per instance buffers so is this correct? Is there any specific use case where all the per instance buffers can be shared?

TGE: 

1. The documentation on TGE shows only one per instance buffer of size 32 bytes. The TGE demo code has a tgeHeap array of size 512 bytes. It looks like this array is used for allocating the 32 byte buffer so the array could be reduced to size 32 bytes. Is this correct? Would there be any problems with changing this to use malloc() instead of the fixed array?

2. The buffer is listed as not volatile. Will problems occur if it is shared between channels and the configuration is set each time TGE runs? It looks like this requires a call to tgeInit() so it would be reinitialized each time it is used, but is it actually saving anything from the previous use? Since it is only generating tones I don't see any reason for it to use the same instance each time it is used other than to save MIPS by not having to reinitialize each time if the same tone and volume are used. 

VAU: 

1. What are the differences between the XDAIS and ECO implementations? I don't see any reason to use XDAIS since ECO has lower memory and MIPS requirements. Is there something I'm missing here?

2. The demo code appears to use its own heap implementation. Would there be any problems with changing it to use malloc() calls instead? 

3. Similar to question 3 for TDU, the documentation lists per instance buffers, but one buffer is listed as scratch. Can the scratch buffer be shared by all channels and only the dedicated buffers be allocated per channel? Is there any specific use case where the dedicated buffers can be shared as well?

ECU:

1. Similar to above questions, ECU uses its own heap managment (it looks like it uses mhm functions) can these be replaced with malloc() and memalign() calls without any problems?

2. Again similar to above questions, the per instance buffers have scratch and dedicated buffers. Can the scratch buffers be shared between channels without problems? Are there any use cases where all of these per instance buffers can be shared between channels without problems?

Regards,

Chris Johnson

Signalogic

  • 0
    Expert 1715 points

    I think I was too broad and open-ended in my original post. Specifically for now, I'm interested in the wording used in the documentation for the VoLIB modules. Each module shows memory usage in tables that are labelled per instance. In these tables are scratch buffers and dedicated buffers. Can the scratch buffers be shared between instances and if not, do they need to remain untouched between subsequent processing calls for a given channel? (I'm confused on the wording of scratch vs dedicated in a table labelled per instance data buffers)

    One other question in the same line. Most of the modules use their own heap memory implementation. I assume the sizes are based on some X number of channels. If I want to use more or less channels, I assume I can just change the size of the buffers used for heap memory. Is there any reason to use these heap memory implementations over standard malloc()/free() calls? TDU for instance doesn't use its own heap memory implementation is there any reason why it wouldn't work with its own heap memory implementation rather than the malloc()/free() calls?

    Regards,

    Chris

  • 0 in reply to Chris Johnson1
    TI__Mastermind 18320 points

    Chris,

    I went ahead and moved this thread over to the device forum to help get it a faster response.

  • 0 in reply to David Friedland
    Genius 3420 points

    David-

    Thanks for moving the thread for us.  The root of our question is how data buffers are used.  In the TI TDU algorithm, there are 938 bytes of dedicated buffers and one 1024 byte scratch buffer, so even if the scratch buffer can be shared between instances 938 bytes adds up quickly.

    For example if we are running 2048 channels (high capacity voice infrastructure application), then we need 1 MByte of heap.  That does not seem normal -- and is not in line with other VoLib algorithms, so this is the basis of our question.  What are our options?

    -Jeff
    Signalogic

  • 0 in reply to Jeff Brower73
    TI__Guru* 95265 points

    For each Volib module, it may use some dedicated buffers and scratch buffers per instance/channel. For the dedicated buffers, this is used per channel. For scratch buffers, they can be shared among multiple channels. After the scratch buffer data is processed by an instance, there is no use to keep it anymore. In your framework, you need to make sure no 2 channels or more access the same scratch buffer at the same time. For exmaple, assuming channel A is using scratch buffer, than an interrupt came in, inside ISR, channel B starts to process the same scratch buffer, this would cause the problem.

    For the heap, test code of many modules allocated a fixed/big heap size, this is for our test application. There is no issue if you want to allocate it dynamically using malloc, based on the number of channels you used.

    For the scratch buffer issues, we are only aware of CPT detection issue you mentioned, if you don't use CPT. It should be fine.

    There are limitations from both memory and MIPS sides that how many channels you can run on a chip. On C55x  we have 32 channels/core * 6 cores = 192 channels (TNETV3010). On C64x+, we have 84 channels/core * 6 cores = 512 channels. Note sure running 2048 channels is on C66x or not, we don't have full voice solution on C66x, so I don't have the channel density. But I think there are also other modules (like encoder/decoder, VAD, ECAN) in additional to TDU, so you can calculate the memory and MIPS required if it fits.

    Regards, Eric        

  • 0 in reply to lding
    TI__Guru* 95265 points

    In e-mail sent by Jeff,

    On the TDU issue, we need advice.  We can move the per-instance (heap) mem to DDR3, but will that work? 

    [Eric: this can work, but DDR3 is slower to access]

    On the second item (TGE bug at 16 kHz) we need a time-line for a fix (this is a bug that we first reported on e2e).

    [Eric: We don't have a timeline for next release of VoLIB]

    Regards, Eric

  • 0 in reply to lding
    Expert 1715 points

    Eric,

    Thanks for the replies. This clears up a lot and is helpful. I have a few more questions, though.

    For higher channel capacity, it seems like there's large heap memory requirements when using multiple VoLIB modules. It looks like the most straightforward way to manage this is to use the MHM VoLIB module and allocate an area of DDR3 as heap. I get that this will be slower, but it will eliminate any memory issues. Maybe we will need to change this at some point for performance reasons, but right now using DDR3 is the quickest solution. Is there any documentation on MHM? I haven't been able to find any. It looks very simple to use. I just want to make sure I'm not making any false assumptions. 

    I also wanted to find out about the differences between the Lite and Full version of the TDU. When I change the settings to Lite, it looks like the code hangs in the tduSendIn() call. I think we want to use Full anyway, but what is the difference between these two and why might I be seeing this behavior with Lite?

    Lastly, VAU has XDAIS and ECO options. From the VoLIB documentation, it looks like ECO has lower memory and MIPS requirements. What is the different between these two and is there any reason to use XDAIS?

    Regards,
    Chris

  • 0 in reply to Chris Johnson1
    TI__Guru* 95265 points

    Chris,

    Can you clarify what is MHM and where in Volib it was mentioned? For the TDU Lite and Full version, lite verison only detects a very limited modem tones, all other tone detector are disabled, so much less memory requirement.

    For the XDAIS and ECO option, ECO is used in our internal voice gateway product, XDAIS is the standard API for modules used externally. I will double check if VAU does supports both XDAIS and ECO interface.

    Regards, Eric

     

  • 0 in reply to lding
    Expert 1715 points

    Eric,

    Thanks for the reply.

    MHM is used by the ECU demo code provided with Volib . There's a folder for MHM under:
    \ti\volib_C66_2_1_0_1\packages\ti\mas\mhm

    I tried implementing MHM and noticed that the size for creating the heap is only 16-bits. Also, there's no way to control alignment with the APIs. This won't work for our implementation, so I will be using SYSBIOS heapMem instead.

    Regards,
    Chris

  • 0 in reply to Chris Johnson1
    TI__Guru* 95265 points

    Chris,

    Just let you know that VAU module supports both XDAIS and ECO interface.

    Regards, Eric