The code modifications are correct. The problem is related to the computational power.
Basically ,if you use an audio frame size that is half of the default one (10ms instead of 20ms), it doesn’t mean that Opus takes half of the MIPS to encode/decode it. So you always need to find a compromise between audio frame size, bitrate and MCU computational power.
Attached you can see 3 slides that show the profiling in 3 different configurations.
In each slide you can see the time used by the MCU to acquire an audio sample, encode it and decode the received audio frame. Since the streaming is done in real time, in order to obtain a correct full-duplex communication, Opus must take for encoding and decoding less time than the audio acquisition (10 or 20 ms).
- The first slide is based on the default configuration: Frame Size=20ms, Bitrate=24kbps. As you can see, encoding+ decoding phases take less than 20ms.
- The second slide is based on your configuration: Frame Size=10ms, Bitrate=24kbps. As you can see, it sometimes happens that Opus takes more than 10 ms just to encode an audio frame. This causes the clicks in the audio output.
- The third slide is based on a compromise between frames size and bitrate: Frame Size=10ms, Bitrate=14kbps (still good audio quality). Opus can encode and decode the audio stream in time.
Basically, lower the bitrate in order to use a smaller frame size.
Two other suggestions:
- Using GCC allows a better optimization of Opus using inline function, so use the STM32CubeIDE project to reach better performances.
- Opus resources demand depends also on the acquired audio type: silences request less MIPS to be encoded. Instead, if you acquire for example a tone, Opus requires more time to encode it. So the parameters should be adjusted accordingly.
Hope this is clear!
