AnsweredAssumed Answered

STM32Cube USB Audio class driver bugs

Question asked by gorcs.gergely on Nov 21, 2014
Latest reply on Jan 29, 2015 by baroudi.badreddine

I've ported the Audio Speaker demo from SMT32F4xx-G Evalboard to STM32F4-Discovery.
I found some strange things during that.

There is a function in the driver strucure with two possible parameters that can send the audio to the I2S DAC:
  AUDIO_COMMAND_PLAY  which invokes BSP_AUDIO_OUT_ChangeBuffer

Here is the function
  * @brief  Handles AUDIO command.        
  * @param  pbuf: Pointer to buffer of data to be sent
  * @param  size: Number of data to be sent in bytes
  * @param  cmd: Command opcode
  * @retval Result of the operation: USBD_OK if all operations are OK else USBD_FAIL
static int8_t Audio_PlaybackCmd(uint8_t *pbuf, uint32_t size, uint8_t cmd)
    BSP_AUDIO_OUT_Play((uint16_t *)pbuf, size);
    BSP_AUDIO_OUT_ChangeBuffer((uint16_t *)pbuf, size);
  return 0;

The comment says we need to pass the size parameter in bytes, and is used that way in upper layers, so clear so far.

However in the BSP packages I can see that these two functions are used different size parameters for the DMA:

BSP_AUDIO_OUT_Play uses a division by the sample bitdepth which is correct if we passed the number of  bytes (not samples) to the previous function.
HAL_I2S_Transmit_DMA(&haudio_i2s, pBuffer, DMA_MAX(Size/AUDIODATA_SIZE));

BSP_AUDIO_OUT_ChangeBuffer uses the number of bytes and not have the dvision by 16bits, so it cannot be correct.
HAL_I2S_Transmit_DMA(&hAudioOutI2s, pBuffer, Size);

Can anyone tell my what is the reason behind, or is it just a bug?

Thank you.