read-out of >8 PDM microphones via USB Topic is solved

[pthomas]

Hello everyone,

for my research we're doing some experiments with microphone arrays and digital PDM microphones. I'm working with the xCore-200 eXplorerkit, and I would like to process 16 PDM microphones.
I used the USB audio library to interface with the explorerkit as an audio card and record data from all microphones. For 8 microphones, this works fine, but I can't get it working for 16 microphones. In the USB audio design guide I've read that the current PDM mic integration in USB Audio limits itself to 8 microphones. Is there a reason for this - is there a workaround?
I would like to access/record data of all 16 array microphones for processing lateron...

Thanks!

[infiniteimprobability]

Hi,
in short there is no technical reason why you shouldn't increase this to 16 channels. The USB reference design is more than capable of handling 16 channels, especially since the rate is so low (16KHz or 48KHz max) and lib_mic_array supports multiple instances of the 8 channel system. In the USB audio reference design, you will obviously need to change the USB so that:

Code: Select all

NUM_PDM_MICS      16
NUM_USB_CHAN_IN    (8)

However, the file sc_usb_audio/module_usb_audio/pdm_mics/pdm_mic.xc assumes 8 mics (one pdm front end and 2 decimators) so you will need to modify this.

You will need to double up on everything including assigning a second 8b port for the mic input (although they should be able to share the same clock) and have 2 front ends and 4 decimators. This means 6 cores + buffer core which fits fine one one tile. The other tile can do the USB bit..

For starters, the modified pdm_mic function will look something like this (I have not compiled this):

Code: Select all

void pdm_mic(streaming chanend c_ds_output[4])
{
    streaming chan c_4x_pdm_mic[4];

    /* Note, this divide should be based on master clock freq */
    configure_clock_src_divide(pdmclk, p_mclk, 2);
    configure_port_clock_output(p_pdm_clk, pdmclk);
    configure_in_port(p_pdm_mics_0, pdmclk); //Both 8b pdm inputs clocked from same source
    configure_in_port(p_pdm_mics_1, pdmclk);
    start_clock(pdmclk);

    par
    {
        mic_array_pdm_rx(p_pdm_mics_0, c_4x_pdm_mic[0], c_4x_pdm_mic_[1]);
        mic_array_decimate_to_pcm_4ch(c_4x_pdm_mic[0], c_ds_output[0]);
        mic_array_decimate_to_pcm_4ch(c_4x_pdm_mic[1], c_ds_output[1]);

        mic_array_pdm_rx(p_pdm_mics_1, c_4x_pdm_mic[2], c_4x_pdm_mic[3]);
        mic_array_decimate_to_pcm_4ch(c_4x_pdm_mic_[2], c_ds_output[2]);
        mic_array_decimate_to_pcm_4ch(c_4x_pdm_mic[3], c_ds_output[3]);
    }
}

You get the general idea?

One thing you may need to consider is using UAC1 or UAC2. UAC2 is limited to FS USB so 12Mbps. So 24b * 16ch would be limited to something like 24KHz. - you would need UAC2 to do 48KHz at 16ch and that means a UAC2 driver on Windows (currently). If you chose to use 16b @ 16KHz then UAC1 is fine.

[pthomas]

Hi infiniteimprobability,

thanks for your reply!
I already did the upgrade to the code, as you suggested. Good to hear you confirmed my adaptations.

However, it seemed the problem was in my sound acquisition on my laptop. I'm using the TUSBAudio control panel together with Labview standard sound acquisition tools (my measurement framework is using Labview). Apparently, the standard Labview sound acquisition toolbox isn't able to control the soundcard (cannot set the samplefrequency) and can't handle more than 8 channels - I assume it is using Windows configuration tools.

I changed the standard Labview sound acquisition with an acquisition based on ASIO drivers, and now I'm perfectly able to control the TUSBAudio Control Panel (set sample frequency) and record 16 channels (even at 48kHz, 32bits) - the USB Audio device is UAC2.0...

Thanks!

[infiniteimprobability]

now I'm perfectly able to control the TUSBAudio Control Panel (set sample frequency) and record 16 channels (even at 48kHz, 32bits)

Thanks for the feeding back your success and the tip about using ASIO! Glad to know that the theory works. Like I said, it's all been designed to handle this configuration, but always encouraging to hear that it's all behaving properly for you.