Bug in Audio Codec Driver

bluexav · ‎2012-10-20

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 */

Codec_Play();

/* 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;

}

#audio-codec-cs43l22

bluexav · ‎2012-10-30

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 :

M0NKA · ‎2012-11-02

Posted on November 02, 2012 at 09:30

Hi,

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