Showing results for 
Search instead for 
Did you mean: 

Bug in Audio Codec Driver

Associate III
Posted on October 20, 2012 at 10:24

Hi !

I'm talking about stm32f4_discovery_audio_codec.c v1.1.0 for CS43L22 .

It is used in the record & playback audio demo and you can find it in the ''utilities'' folder.

I've struggled a lot to make the circular buffer mode DMA work !

There seems to be a confusion in the audio data size counting method : sometimes bytes (8 bits) and other times half words (16 bits).

I would suggest to use Size variable to always count in half word.

It will affect :

uint32_t EVAL_AUDIO_Play(uint16_t* pBuffer, uint32_t Size)




  /* Set the total number of data to be played (count in half-word) */


  AudioTotalSize = Size;




  /* Call the audio Codec Play function */






  /* Update the Media layer and enable it for play */  


  Audio_MAL_Play((uint32_t)pBuffer, (uint32_t)(DMA_MAX(Size)));




  /* Update the remaining number of data to be played */


  AudioRemSize = Size - DMA_MAX(AudioTotalSize);




  /* Update the current audio pointer position */


  CurrentPos = pBuffer + DMA_MAX(AudioTotalSize);




  return 0;



Associate III
Posted on October 30, 2012 at 17:11

Another weird thing for me is why are audio samples typed as uint16_t ? They are signed integers.

This has caused a problem in my project when converting one format in an other.

For converting 32bits floats to 16bits ''unsigned'' integers, GNU ARM gcc needs :

(uint16_t)((int16_t)((32767.0f) * y ))

But IAR seems all right with :

(uint16_t)((32767.0f) * y )

Cheers !

By the way here is a video of my sound gadget :

Posted on November 02, 2012 at 09:30


Nice effects! I am no expert about audio processing, but it seems the I2S DMA hardware

deals with unsigned buffers. Then in the IRQ routine, a conversion to/from float is needed

if you are using some FIR that needs floats for example. And a cast to the ptr is not enough,

but rather loop with converting each value.

BR, Chris