Ux Recording - Onboard mic works, but not the analog mic

[audio]

I downloaded the package from here: https://www.st.com/en/embedded-software/x-cube-azrtos-h7.html

It is not yet available on MX when searching for example code. 

Anyways, so I am able to run the UX_Device_Recording which is cool. I notice that it uses the onboard mic, which is 

  AudioInInit.Device = AUDIO_IN_DEVICE_DIGITAL_MIC;

 But I want to use the analog microphone that comes with the headset - available in CN17. So I change it to 

  AudioInInit.Device = AUDIO_IN_DEVICE_ANALOG_MIC;

And now it's giving a static noise, but no mic input is captured. 

Any idea why?

[Peter BENSCH]

You mentioned e.g. UX Recording and STM32H7, but an unsuspecting person wouldn't know which board you are currently working with. However, I took the trouble to look through your previous questions and was able to see the STM32H743I‑EVAL (MB1246) there, correct? It is always helpful to provide all necessary information, such as links to websites.

The UX_Device_Recording example is configured for the on‑board digital MEMS mic, so simply changing:

AudioInInit.Device = AUDIO_IN_DEVICE_ANALOG_MIC;

is not sufficient. You also need to:

1. configure the codec input for the MIC input on CN17 (enable the right analog input, mic‑bias and PGA gain, as done in the board’s standard audio‑record examples for H743I‑EVAL)
2. ensure the audio BSP init call (BSP_AUDIO_IN_Init() / BSP_AUDIO_IN_Record() parameters) matches the analog‑mic configuration

Hope that helps?

Regards
/Peter

[audio]

Hello Peter, 

Thank you for your response. You are absolutely correct, sorry I've used the forum so much, I forgot to specify the necessary details in the first round. You are correct on the board you mentioned. 

1. Okay, so I do need to go into the wm8994.c file and configure accordingly, because at the moment, I didn't want to get into the drivers just yet in case the BSP already has covered it. I did look into the other audio-record examples, and it seems that BSP and drivers are common across examples, which is why I didn't think to look there. As of now, in the stm32h743i_eval_audio.c file, 

AUDIO_IN_DEVICE_ANALOG_MIC

corresponds to 

WM8994_IN_LINE1

which does not have micbias2 or other configurations needed to have MIC input. Simply switching that to WM8994_IN_MIC1 did not work either (it introduced the DC offset, which make sense because of the micbias, but not working as it should). So I wanted to check in first before I mess around with the wm8994.c files I in case I missed something here. 

2. I have this currently set up to call BSP_AUDIO_IN_Init() in app_usbx_device.c... 

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

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

And in the BSP_AUDIO_IN_Init(), the logic for instance 0 is included (0 being SAI line, and that's where CN17 lies)

As for BSP_AUDIO_IN_Record(), the function does not seem to have a logic for instance 0 as it focuses more on 1 - so that's probably where I should investigate in. 

Any other thoughts?

Thank you

[audio]

Hello @Peter BENSCH 

I haven't heard back yet. Wanted to have your guidance on this. 

thank you

[Peter BENSCH]

I was at Embedded World in Nuremberg, so I wasn't able to help more deeply in the community for several days.

Just switching to AUDIO_IN_DEVICE_ANALOG_MIC is not enough, because the BSP was really written and validated for on‑board digital MEMS mic and line‑in via the WM8994, not for the headset mic on CN17 as a drop‑in replacement. AUDIO_IN_DEVICE_ANALOG_MIC > WM8994_IN_MIC1 is necessary but not sufficient, you must also mirror the full mic path configuration:

• enable the right MIC input
• enable MIC bias
• set PGA gain, input mixer, HPF etc. similar to the working audio‑record examples.

If you only see a DC offset with MIC1, it usually means bias ON, path not fully routed/gained, and/or wrong channel.

If BSP_AUDIO_IN_Record() has no logic for instance 0 in your version, you could copy/adapt the SAI‑recording code from a working BSP example (non‑Azure RTOS audio record for H743I‑EVAL) and add the missing branch for instance 0, or, as a quick test, bypass the BSP and configure SAI+DMA yourself exactly as in the standard audio‑record example, then just feed the recorded buffer into the USBX stack. Static‑like noise with DC offset and no speech usually means SAI+DMA are running, but the codec input path is misconfigured.

Why not first get headset‑mic recording working in a bare audio‑record example (no USBX), using the same BSP and codec driver?