USBX Ux Device Audio - Playback and Recording

[audio]

I have Playback set up and running. I also have recording set up as well. It enumerates. It shows up as STM32 Microphone. But it does not capture anything. 

I notice that playback is not playing sounds either. So I traced it to this: as soon as I have BSP_AUDIO_IN_Init() called, playback doesn't play sounds. 

I wonder if there's an issue with having both instances be 0?

  // Initialize Audio Play and Record structures
  AudioPlayInit.Device = AUDIO_OUT_DEVICE_HEADPHONE;
  AudioPlayInit.ChannelsNbr = 2;
  AudioPlayInit.SampleRate = AUDIO_FREQUENCY_48K;
  AudioPlayInit.BitsPerSample = AUDIO_RESOLUTION_16B;
  AudioPlayInit.Volume = VOLUME_SPEAKER_DEFAULT;

  AudioRecordInit.Device = AUDIO_IN_DEVICE_ANALOG_MIC; // Use instance 0 SAI/codec
  AudioRecordInit.ChannelsNbr = 2;
  AudioRecordInit.SampleRate = AUDIO_FREQUENCY_48K;
  AudioRecordInit.BitsPerSample = AUDIO_RESOLUTION_16B;
  AudioRecordInit.Volume = VOLUME_MICROPHONE_DEFAULT;

  // Initialize Audio Output Device
  if(BSP_AUDIO_OUT_Init(0, &AudioPlayInit) != BSP_ERROR_NONE)
  {
    Error_Handler();
  }

  // Initialize Audio Input Device
  if (BSP_AUDIO_IN_Init(0, &AudioRecordInit) != BSP_ERROR_NONE)
  {
    Error_Handler();
  }

The reason why both instances are 0 is because I want to use SAI/codec lines, and I have a headset that is a headphone and microphone in the same jack. 

Thoughts on why initializing the input device kills the playback?

[audio]

Upon further investigation, it appears that inside BSP_AUDIO_IN_Init() in stm32h743i_eval_audio.c, this block 

/* Prepare haudio_out_sai handle */
      haudio_out_sai.Instance     = SAI1_Block_A;
      mx_config.AudioMode         = SAI_MODEMASTER_TX;
      mx_config.ClockStrobing     = SAI_CLOCKSTROBING_FALLINGEDGE;
      mx_config.OutputDrive       = SAI_OUTPUTDRIVE_ENABLE;
      mx_config.Synchro           = SAI_ASYNCHRONOUS;
      mx_config.SynchroExt        = SAI_SYNCEXT_DISABLE;
      mx_config.SlotActive        = CODEC_AUDIOFRAME_SLOT_0123;
      if(MX_SAI1_Block_A_Init(&haudio_out_sai, &mx_config) != HAL_OK)
      {
        /* Return BSP_ERROR_PERIPH_FAILURE when operations are not correctly done */
        ret = BSP_ERROR_PERIPH_FAILURE;
      }

means it re-initializes the SAI1 Block A, which Playback uses, causing Playback to stop working. 

Also, this block 

#if (USE_AUDIO_CODEC_WM8994 == 1U)
      /* Initialize the codec internal registers */
      if(WM8994_Probe() == BSP_ERROR_NONE)
      {
        WM8994_Init_t codec_init;

        /* Fill codec_init structure */
        codec_init.Frequency    = AudioInit->SampleRate;
        codec_init.OutputDevice = WM8994_OUT_NONE;
        if(AudioInit->Device == AUDIO_IN_DEVICE_ANALOG_MIC)
        {
          codec_init.InputDevice = WM8994_IN_LINE1;
        }
        else /* (AudioInit->Device == AUDIO_IN_DIGITAL_MIC) */
        {
          codec_init.InputDevice = WM8994_IN_MIC2;
        }
        switch (AudioInit->BitsPerSample)
        {
        case AUDIO_RESOLUTION_32B:
          codec_init.Resolution   = 3;
          break;

        case AUDIO_RESOLUTION_16B:
        default:
          codec_init.Resolution   = 0;
          break;
        }
        /* Convert volume before sending to the codec */
        codec_init.Volume       = VOLUME_IN_CONVERT(AudioInit->Volume);

        /* Initialize the codec internal registers */
        if(Audio_Drv->Init(Audio_CompObj, &codec_init) != 0)
        {
          ret =BSP_ERROR_COMPONENT_FAILURE;
        }
      }
#endif  /*USE_AUDIO_CODEC_WM8994 == 1)*/

re-initializes the codec as well. Once both are commented out, the playback works. 

I guess we do need to have some kind of guarding to allow playback or recording, and both. 

[FBL]

Hi @audio 

Indeed, the STM32H743I-EVAL BSP does not support simultaneous playback and recording (full-duplex) on the same SAI interface by simply calling BSP_AUDIO_OUT_Init and BSP_AUDIO_IN_Init sequentially. The audio IN and OUT are exclusive on the same SAI interface, and enabling both in parallel is not possible without customization. This is due to the risk of SAI configuration being overwritten and codec output configuration not being preserved when enabling the input path.