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.

TM4C129XNCZAD: OPUS codec abort codification

Part Number: TM4C129XNCZAD
Other Parts Discussed in Thread: EK-TM4C1294XL

I'm running spma 076 example from Texas (codec OPUS) on TM4C129XNCZAD, when I'm encoding a wav file the process is aborted after the memory allocation.
Knowing that the encoder codes frame by frame, I noticed that after some frames coded the process is aborted. For that reason I think that the memory allocation is running without problems and the memory De-Allocation is not working properly. I think that because after some frames of encoding the system cannot allocate more memory for encoding the next frames.

Can someone help me solving this problem or identifying the reason of it.

Please see the link with the example that I use: www.ti.com/.../spma076.pdf

  • Hello Joao,

    What are your heap and stack settings for your project? Have you set them in accordance to the example code?
  • Hello Ralph, 

    Thank you for the answer, initially my heap and stack settings were the same as the example settings, with that settings I can only encode half of the frames of a Wav file with more or less 5 seconds length.

    If I add more heap size(maximum heap size allowed for the TM4C memory) I can code more frames for the same file, more or less 75% of the file, as you can see in next picture.

    I modify heap size from 98304 (origin example) to 230000.

  • Hello Joao,

    Which of the projects are you using from the app note? Are you doing this through an SD card?

    Do you have any details about the .wav file being processed? Like sampling rate, etc.
  • Hello Ralph,
    I'm using opus_enc_dec project from example spma076 from texas. I'm using internal memory to store the .wav file (~7000 Bytes) and I import file through "load memory" by code composer studio. The output from the encoder is also stored in the internal memory (in a static vector). I'm not using SD Card because is not usefull for my project.

    .wav details:
    Sample rate: 8000
    Bits per sample: 8
    Channels: 1

    Thanks
  • Hello Joao,

    The Opus encoder/decoder uses up quite a lot of memory so we do not recommend the use of internal device memory for this at all. That is a prime reason why the SD card interface was leveraged. The limitation you are seeing may be directly related to that.

    An additional question, what frame size is being used?
  • Hello Ralph,

    The frame size is default from the project (20 ms).

    Today I tried to insert a smaller .wav file in internal memory (half the size of the previous file) and I was able to encode the file without problems. In file memory.c (ccs) exists a function named "memmap()" but I can't use it, I already defined MALLOC_DEBUG. 

    I wanted to know how many allocs and free memories I was using during runtime, so I tried to modify the memory.c but unfortunately that change does not affect the project. How can I run the project with my modified memory.c file?

    Regards

  • Hello Joao,

    Can you send me your CCS project so I can try and replicate the issue on my hardware? I have both the DK-TM4C129X and the EK-TM4C1294XL so either board is okay for me to work from.
  • Hello Ralph,

    OK. I sent the project here. If you have any questions about the project, ask me.

    Thanks

    opus_enc_dec_my.rar

  • Hello Joao,

    Thank you, I have been working at building it (had to resolve issues with the opus library first since I don't have a D drive...) and hit a couple functions in your program that are not declared properly.

    minit is one, and UARTgetdata is the other

        if (need_mem_init)  minit();
    
    	numbytes = UARTgetdata(pcWriteMem, 15000);

    Can you provide me steps on how to get those functions to compile? At least the minit one since that seems central to your memory setup. If you think the UART one is irrelevant I can comment it out.

  • Hello Ralph,

    Those functions were mine and I did that to debug the code, I already commented them and I'll attach the project to this, you can substitute the main function. The UART one is irrelevant in this part.

    3531.opus_enc_dec_my.rar

    Thanks

  • Hello Joao,

    I have gotten the project to compile now properly, thank you. Unfortunately I have been running into some issue with the DK board I have, so I may not be able to provide more feedback until next week.
  • Hello Joao,

    I need to get a fresh DK board to be able to run your example properly, so it will be a few more days until that arrives and I can further debug. If you have made any progress on your end let me know and I can try and help best I can.

    Sorry for the delay in support.
  • Hello Ralph,

    Throughout these days, I only verified that for short .wav files (less than 1 second) it can encode and decode without problems. 

    Thanks

    João 

  • Hello Joao,

    Sorry for the delay but I have the new board up and running and have the example running now. Reading through the posts I should have asked for this sooner, but can you provide a .wav file that has the issue so I can upload it with the load memory feature in CCS to test the exact issue you are seeing? I don't think any of the ones I have would fit within the device memory. Also what command line do you use to trigger the conversion as there aren't any actual file names involved with all the data being in memory?
  • Hello Ralph,

    I use "enc xxx xxx" line command to trigger the encoding and "dec xxx xxx" to trigger the deconding where "xxx" can be anything.

    I have been improving the code during these days, so here I send the main file, you just need to replace the entire text of the file. 

    The wav file that I can code without problems is the veryShort_wav.bin that is just a sample from the  clean_wav.bin. You must load the file .bin to the address of "array_exemplo" with type_size = 32 bits.

    Thanks

    files.rar

  • Hello Joao,

    Thank you, I have been able to recreate the issue you have been seeing on my board as well where the loader_exit occurs after an ALLOC call during encoding the clean_wav.bin file.

    Unfortunately, the issues I had with the board caused a bit of a timing issue as now the engineer who helped develop the OPUS code is out of office, so while I will look into this further best I can, I am not sure I will make any positive headway until conferring with them.
  • Hello Ralph,

    Do you have already any results?

    Thanks 

    João Louro

  • Hello Joao,

    Unfortunately not, and I won't be able to look at it further this week. Next week my colleague will be back and I can speak with him about the topic.
  • Hello Ralph,

    Do you have already any results?

    Best Regards

  • Hello Joao,

    Unfortunately not yet. The issue has been open for me the whole time, but since the engineer I need to work with and I are in different groups, it's been challenging to get our schedules aligned. We have set time on Tuesday to look at this further.
  • Hello Joao,

    My colleague and I have finally been able to devote proper time to working on this issue in attempt to uncover how to solve the problem. The core of the issue is definitely that the heap is running out of space, which is why your increase of the heap allowed the result to process further.

    The problem has shown up because you are processing the data in an atypical way for Opus. The whole idea behind Opus is so try and do the encoding in real time, and the processor running the Opus library should be reading out chunks of data, encoding it, and then sending the result back. This is the principle of how the example provided by TI works with the SD Card.

    What you are doing with storing the whole data in the MCU memory and processing from that is not how the Opus library or the TI example was intended to be used.

    Because of that, for us the root cause of why the heap is running out of space is unclear, but one potential theory could be that there is a memory leak due to the Opus source code which surfaces only when trying to do an application like what you are attempting. That would be a question you could direct towards the Opus Codec group (Xith), and see if they are aware of any possible memory leaks with the source code provided by them.

    Our stress tests for Opus including encoding 3 minute long files via Ethernet with the MCU handling both the Ethernet Stack and the Opus encoding has shown no issues with memory when the heap and stack are configured per the app note.

    Unfortunately, from our end at TI, there isn't much else we can offer regarding this issue because
    1) It deviates heavily from the intention of Opus encoding and why we chose to make the Opus example+App Note
    2) The issue seems to be due to the Opus source code, as we have not seen any issues with the heap for any of the stress tests done that is applicable to the Opus example we offered.
  • Hello Raph

    Thank you for your help.

    Can you please send me the project solution for the "3 minute long files via Ethernet with the MCU handling both the Ethernet Stack and the Opus encoding". I want to test this implementation and make further remarks afterwards.

    Thanks,
    João
  • Hello Joao,

    Certainly, you can find all the details in this TI Design including software: www.ti.com/.../TIDM-TM4C129POEAUDIO