DMIC Dual Microphones DMA

Hi Brandon,

How to configure the DMIC for using DMA to receive dual microphones data (AUDIO->DMIC_DATA)?

I tried below configuration, but it does not work.

Sys_Audio_DMICDIOConfig (DIO_6X_DRIVE | DIO_LPF_DISABLE | DIO_NO_PULL, DMIC_CLK_PIN, DMIC_DATA_PIN, DIO_MODE_AUDIOCLK);

#define DMIC_AUDIO_CFG (DMIC0_ENABLE |
DMIC1_ENABLE |
DECIMATE_BY_200 |
DMIC_AUDIOCLK |
DMIC0_DMA_REQ_ENABLE)

Sys_Audio_Set_Config (DMIC_AUDIO_CFG);

#define DMIC_CFG (DMIC0_DCRM_CUTOFF_20HZ |
DMIC1_DCRM_CUTOFF_20HZ |
DMIC1_DELAY_DISABLE |
DMIC0_FALLING_EDGE |
DMIC1_RISING_EDGE)

Sys_Audio_Set_DMICConfig (DMIC_CFG, 0);

#define DMA_RX_CONFIG (DMA_LITTLE_ENDIAN |
DMA_ENABLE |
DMA_DISABLE_INT_DISABLE |
DMA_ERROR_INT_DISABLE |
DMA_COMPLETE_INT_ENABLE |
DMA_COUNTER_INT_DISABLE |
DMA_START_INT_DISABLE |
DMA_DEST_WORD_SIZE_32 |
DMA_SRC_WORD_SIZE_32 |
DMA_DEST_ADDR_INC |
DMA_PRIORITY_0 |
DMA_TRANSFER_P_TO_M |
DMA_SRC_ADDR_STATIC |
DMA_SRC_DMIC |
DMA_ADDR_CIRC)

/* Configure DMA channel for DMIC data transfer */
Sys_DMA_ChannelConfig ( RX_DMA_NUM,
DMA_RX_CONFIG,
SUBFRAME_LENGTH,
0,
(uint32_t)&(AUDIO->DMIC_DATA),
(uint32_t)dmic_buffer_in);

Hi @NEO,

In order to implement dual channel DMIC audio, you will need to make use of both DMIC0 and DMIC1 interfaces. Each of the interfaces will handle one channel of audio on its own.

There is a limitation when using the DMIC in DMA mode with two channels, as there is only 1 DMIC DMA Request line. Due to this, you will be limited to only receiving 16bit audio samples instead of the 18bit that can be achieved using interrupts.

If this limitation is not a problem, you can use the DMIC DMA setup and sample processing directly from the ‘remote_mic_tx_raw/coex’ sample firmware. These configurations can be found in the following files and fucntions:

  1. Initialize_Raw_DMIC_Input_Type()’ function within the ‘app_init.c’ file
  2. DMA_RX_CONFIG’ define within the ‘app.h’ file (specifically the DMIC related setup on line 199)
  3. rx_DMA_ready_DMIC()’ function within the ‘app_func.c’ file

If this limitation is not a problem, you can use the DMIC DMA setup and sample processing directly from the ‘remote_mic_tx_raw/coex’ sample firmware. These configurations can be found in the following files and fucntions:

The configuration that I have used are from ‘remote_mic_tx_raw/coex’ sample firmware, but it does not work.

Hi @NEO,

One thing to note, there is a known issue with the ‘remote_mic_tx_raw/coex’ sample application that causes the DMIC Audio Clock frequency to bet set too high.

Since the System Clock has been updated to 48MHz, the Audio Clock Prescale value must be updated from 5 to 15. This can be done by making the following changes to the ‘Initialize_Raw_DMIC_Input_Type()’ function within the ‘app_init.c’ file on line 399:

    /* Configure AUDIOCLK to 3.2MHz */
    Sys_Clocks_SystemClkPrescale1(AUDIOCLK_PRESCALE_15);

The System Clock is prescaled by 3 to get 16MHz.
AUDIOCLK_PRESCALE is 5, so 16MHz/5 = 3.2MHz.
There is nothing wrong with the audio clock which is set at 16KHz after the decimation factor of 200.

The problem is this configuration only have good sound from Right Channel but noise from Left Channel.

Hi @NEO,

The default ‘remote_mic_tx_raw/coex’ sample firmware are setup to use 48Mz System Clock without a prescale value. It sounds like you have updated this to use the 16MHz System Clock instead. Is this correct?

If this is the case, I recommend you first setup our ‘DMIC_OD’ sample firmware to verify that your PDM Microphones are configured properly. This is a much simpler sample application that simply does audio pass-through, but will act as a method to verify the hardware setup.

The default ‘remote_mic_tx_raw/coex’ sample firmware are setup to use 48Mz System Clock without a prescale value. It sounds like you have updated this to use the 16MHz System Clock instead. Is this correct?

Below code is from the ‘remote_mic_tx_raw/coex’ sample firmware. It is not set by me.

/* Enable the 48 MHz oscillator divider using the desired prescale value */
RF_REG2F->CK_DIV_1_6_CK_DIV_1_6_BYTE = CK_DIV_1_6_PRESCALE_3_BYTE;

If this is the case, I recommend you first setup our ‘DMIC_OD’ sample firmware to verify that your PDM Microphones are configured properly. This is a much simpler sample application that simply does audio pass-through, but will act as a method to verify the hardware setup

I have already used this ‘DMIC_OD’ sample firmware to verify that my hardware setup of dual microphones are working fine. Unfortunately, this sample code is only using interrupt but not DMA for DMIC.

Hi @NEO,

You are correct. Only the raw variant has the update to 48MHz, while the coex variant is static at 16Mz.

As for the ‘DMIC_OD’ validation, did you ensure that you used DIO5 button to switch between the left and right channels, and listened to the audio from both to confirm each channel is working as expected? Once we have confirmed that your DMIC setup is passing the expected audio, we can attempt to reproduce the issue on our end.

As for the ‘DMIC_OD’ validation, did you ensure that you used DIO5 button to switch between the left and right channels, and listened to the audio from both to confirm each channel is working as expected? Once we have confirmed that your DMIC setup is passing the expected audio, we can attempt to reproduce the issue on our end.

Yeah, I have used DIO5 to switch between the left and right channels, and the mixed mode. It is working as expected when I point my iPhone speaker close to the respective microphone hole.

Since DMIC only has one DMA request line, I cannot set both DMIC0_DMA_REQ_EN and DMIC1_DMA_REQ_EN. Is it correct?
The sample code only set DMIC0_DMA_REQ_EN.
Should I set DMIC0_DMA_REQ_EN or DMIC1_DMA_REQ_EN?
Logically, it should be DMIC1_DMA_REQ_EN. That is, after receiving DMIC0 and then DMIC1, trigger the DMA.

Which of the below two Sys_Audio_DMICDIOConfig settings is correct?
If I set according to (1), Right-Ch has sound but Left-Ch is noise.
If I set according to (2), Left-Ch has sound but Right-Ch is noise.

  1. Sys_Audio_DMICDIOConfig (DIO_WEAK_PULL_UP, DMIC_CLK_PIN, DMIC_DATA_PIN, DIO_MODE_AUDIOCLK);
    This is used by ‘remote_mic_tx_raw’ sample firmware.

  2. Sys_Audio_DMICDIOConfig (DIO_6X_DRIVE | DIO_LPF_DISABLE | DIO_NO_PULL, DMIC_CLK_PIN, DMIC_DATA_PIN, DIO_MODE_AUDIOCLK);
    This is used by ‘DMIC_OD’ sample firmware.

Hi @NEO,

Okay, it is good to know that the hardware setup is behaving as expected. Now we can focus on the software elements.

For the DMA Request settings, it should be possible to set either the DMIC0 or DMIC1 DMA Request settings, but it is very important to only set one or the other. If both are set and two DMA transfers are configured, it will result in the DMIC0 transfer being triggered mistakenly whenever the DMIC1 is filled, and vice versa.

As for which is better, you should be able to use either as they will both result in a transfer after both DMIC interfaces receive new data (be that “DMIC1 → DMIC0 → DMA Transfer” or “DMIC0 → DMIC1 → DMA Transfer”), but you are correct that it might improve the data continuity if you instead set the DMIC1 to trigger the DMA Request as this will ensure the latest data are in both registers.

For the DMIC DIO Configurations, if you are reporting that the ‘DMIC_OD’ sample application did not have this problem, you should be using the same DMIC DIO settings as this setup. In this case, the ‘DMIC_OD’ sample uses option 2. in your reply.

It is very strange to me that changing these DIO settings will give you different results when 2. was working on both channels in a different sample application. If a different sample application is able to work on both channels with the 2. settings, there is no reason changing the DIO setup should result in any differences in behavior.

As a next step, can you please setup our default ‘remote_mic_tx_raw’ & ‘remote_mic_rx_raw’ sample applications with your DMIC and let me know if you see any performance issues on either channel? This will help us to eliminate any of the custom changes you have made in the COEX version to support DMIC as the issue.

Okay, I will try to setup ‘remote_mic_tx_ raw ’ & ‘remote_mic_rx_ raw ’ sample applications with the DMIC.

I ported DMIC module from ‘remote_mic_tx_ raw ’ to ‘remote_mic_tx_ coex ’, and using option 2, the right channel is always noise, be it using DMA method or Interrupt method for DMIC.

The DMIC hardware module is tested working on ‘DMIC_OD’ sample code using Interrupt method. I modified the ‘DMIC_OD’ sample code to use DMA method, and it also works fine.

I have setup ‘remote_mic_tx_ raw ’ & ‘remote_mic_rx_ raw ’ sample applications with the DMIC. I have tried both system clock of 48MHz and 16MHz for TX. But, there is no sound.

Can you verify that the TX (DMIC) and RX (OD) setup are working at your side?

Hi @NEO,

I can confirm that the ‘remote_mic_tx/rx_raw’ samples are working as expected on my end.

A few things to note during setup:

  1. Make sure the TX firmware is running at 48MHz and that you have updated the Audio Clock prescale value to 15
  2. The TX firmware uses DIO0 as the CLK Pin and DIO1 as the DATA Pin. You will need to set the ‘INPUT_INTRF’ variable within app.h to ‘DMIC_RX_RAW_INPUT’ to configure the firmware for DMIC.
  3. The RX firmware uses DIO0 and DIO1 as the balanced Output Driver audio pins. You will need to set the ‘OUTPUT_INTRF’ variable within app.h to ‘OD_TX_RAW_OUTPUT’ to configure the firmware for OD.

I did follow the above steps, but no sound.

By the way, below image shows some reported issue with smaller SUBFRAME size.
Currently the TX SUBFRAME size is set at 8 which is smaller than 32 samples.
Could this cause noisy problem?

Hi @NEO,

Are you able to hear the ~1s of 1kHz sine wave output on the RX Raw output driver after a restart? This will help us confirm if the RX Raw output driver has been setup properly.

As for the SUBFRAME sizing, this is known to possibly cause periodic noise, but it should not cause the constant noise or lack of audio that you are reporting. That said, if you would like to increase the size of this SUBFRAME buffer, a larger buffer would not hurt.

The Right-Channel noise problem is due to the DMIC module (I use Infineon IM69D130) cannot operate at 3.2MHz audio clock.

The ‘remote_mic_tx_coex’ uses 3.2MHz audio clock and a decimation factor of 200 to get exactly 16KHz sampling frequency.

I lower down the audio clock frequency by using audioclk_prescale_7 and decimation_factor_144. The audio clock is 2.286MHz and the sampling frequency is 15.873KHz. With this setting, I can hear the Right-Channel sound. However, the RM link becomes lost after running for a short while. This could be due to sampling frequency is not exactly 16KHz and therefore affects the RM link operation.

By the way, which DMIC hardware module do you use to test your setup?

Hi @NEO,

I’m glad you have been able to find the root cause of this issue!

As for the RMP drop-out, you are correct that the G.722 codec requires an input sample rate of 16kHz of 16bit sample. If you are not sending in the audio samples at 16kHz, the resulting encoded data will not be able to meet the expected bitrate of the RMP. In short, you must ensure that the audio samples are being received at 16kHz for the codec and RMP to work as expected.

For my testing, I make use of the INMP522 PDM Microphone that is mounted on our RSL10 SENSE evaluation board. While it is only single channel, it is not difficult to reconfigure the sample firmware to test both channels individually.

I just purchased an RSL10 evaluation board and want to use it to implement something like the DMIC Dual Mic and audio streaming applications to my cellphone.

So, very basic questions:

  • can you please tell me where to find documentation for the RSL10 evaluation board showing where and how to connect the microphones?
    -same question for the loudspeakers, or can my laptop speaker be used via the USB connection?

Hi @dpreves Welcome to the Community Forum!

As the assignment/usage of pins is quite programmable, you’ll not find the DMIC or OD connections in the evaluation board manual. Rather, the DMIC_OD sample project’s readme file “readme_dmic_od.md” contains the following:

Hardware Requirements

This application can be executed on any RSL10 Evaluation and Development
Board, and requires two PDM microphones and a headphone. For the RSL10
Evaluation and Development Board, connect:

  • DMIC_CLK to DIO15
  • DMIC_DATA to DIO14
  • Headphone+ to DIO9 through an inductor (e.g. 680 uH)
  • Headphone- to DIO8 through an inductor (e.g. 680 uH)

The inductors are required to filter high frequency currents, unless the
headphone has sufficient self-inductance.