Encoding works as expected on STM32F4 but decoding produces incorrect results compared to Linux

[duchieu91]

I have been testing Codec2 on STM32F4 and Linux platforms. When I perform encoding, the output file is similar on both platforms (STM32F4 and Linux), and the encoded file looks as expected. However, when I attempt to decode the encoded file, the results are different between the two platforms.

On Linux, the decoding produces the correct output, but when decoding on STM32F4, the result is raw data with significant discrepancies and errors, as shown in the attached image. The decoded file on STM32F4 is far from what was expected, and it contains a lot of noise and incorrect values.

I suspect there might be some difference in the decoding process or how the data is handled on STM32F4, but I have not been able to identify the cause. Any help or suggestions on resolving this issue would be greatly appreciated.

[duchieu91]

I have defined EMBEDDED and set up the hardware FPU on STM32F4, but this does not seem to resolve the issue.

[drowe67]

Hi @duchieu91 - yes the output of the decoder looks buggy. Some thoughts:

1. So it's either a bug in your test software or a bug in our SM1000 code.
2. We aren't actively developing this code any more, but do run the ctests from time to time to check it's all working OK. They use special hardware (an old dev kit) so we don't do it that often. So if by chance it's in our code there will definitely be a point in the past (e.g. stm32 ctest maintenance codec2-dev#339) that this code in this repo (or codec2-dev) is fine.
3. Have you used the codec2/stm32 build system?
4. Can you run/reproduce the stm32 ctests?

[duchieu91]

Thanks for answer, but I have successfully built the Codec2 project for STM32F4 as per the provided instructions, although I do not have the S1000 hardware available. After building, I extracted the libcodec2.a library and used it in a separate project, where I only call the codec2_encode() and codec2_decode() functions on kit stm32f4.

[duchieu91]

[tmiw]

Could the manual linking process be screwing stuff up? There are some other flags enabled when we build the SM1000, too, so it might be worth (double) checking https://github.com/drowe67/codec2/blob/main/stm32/CMakeLists.txt if you haven't already.

[duchieu91]

Hi @duchieu91 - yes the output of the decoder looks buggy. Some thoughts:

1. So it's either a bug in your test software or a bug in our SM1000 code.
2. We aren't actively developing this code any more, but do run the ctests from time to time to check it's all working OK. They use special hardware (an old dev kit) so we don't do it that often. So if by chance it's in our code there will definitely be a point in the past (e.g. stm32 ctest maintenance codec2-dev#339) that this code in this repo (or codec2-dev) is fine.
3. Have you used the codec2/stm32 build system?
4. Can you run/reproduce the stm32 ctests?
   Can you show me the actual decoding result on the STM32 for any audio clip?
   This is my result on kit stm32. It is normal?