16 or 24 mic(PDM) to PC as a sound card

If you have a simple question and just want an answer.
superganbu
New User
Posts: 3
Joined: Thu Dec 07, 2017 3:27 am

16 or 24 mic(PDM) to PC as a sound card

Postby superganbu » Mon May 21, 2018 6:33 am

Dears,
We have a project : 16 or 24 mic(PDM) to PC as a sound card,and I have some questions:
1.which driver we need on PC.
2.If we have 2 sound card, can the driver suport them run in one pc;(so we can use two cards 16pdm insead of 32pdm)
3.lib_mic_array: 3.072M to 48K; but we want 48KHZ evan when pdm clk is changed(1MHZ or other), can the lib support this function?

thanks!
User avatar
infiniteimprobability
XCore Legend
Posts: 1079
Joined: Thu May 27, 2010 10:08 am

Postby infiniteimprobability » Mon May 21, 2018 5:50 pm

Dears,
We have a project : 16 or 24 mic(PDM) to PC as a sound card,and I have some questions:
1.which driver we need on PC.

You will need audio class 2 drivers for that many channels, but Windows 10 has those built in now.
2.If we have 2 sound card, can the driver suport them run in one pc;(so we can use two cards 16pdm insead of 32pdm)

Probably not, unless you are not too worried about synchronisation.
Why not just design a single card with 24 mics? It is possible with a 4 tile device.
3.lib_mic_array: 3.072M to 48K; but we want 48KHZ evan when pdm clk is changed(1MHZ or other), can the lib support this function?

I'm afraid not. It is designed for 2.8224 or 3.072MHz. It is technically feasible to re-design all of the filter stages for a different input frequency but a lot of work and qualification.
superganbu
New User
Posts: 3
Joined: Thu Dec 07, 2017 3:27 am

Postby superganbu » Wed May 23, 2018 4:59 am

2.If we have 2 sound card, can the driver suport them run in one pc;(so we can use two cards 16pdm insead of 32pdm)
Probably not, unless you are not too worried about synchronisation.
Why not just design a single card with 24 mics? It is possible with a 4 tile device.

The 4 tile device is OK.
my system is upgrade every year(may 32 or 64..). if two or more cards can worK in one pc, I will not worry about the system upgrade,because I needn't redesign the card.
I am not worry about synchronisation, just can record sound data at the same time.
is it have the funciton?

3.lib_mic_array: 3.072M to 48K; but we want 48KHZ evan when pdm clk is changed(1MHZ or other), can the lib support this function?
I'm afraid not. It is designed for 2.8224 or 3.072MHz. It is technically feasible to re-design all of the filter stages for a different input frequency but a lot of work and qualification.


we are using the RME sound card. I want design the card use the XMOS tech.
We are building a test system for pdm mics. so we need 700 - 3000KHZ , and the sample rate is not too bad for analyzing the mic performance.
I have study The XMOS for two months, can you give me some advice ?
I think it is imposible to me to re-design all of the filter stages, are you agree?

Thanks
User avatar
infiniteimprobability
XCore Legend
Posts: 1079
Joined: Thu May 27, 2010 10:08 am

Postby infiniteimprobability » Wed May 23, 2018 4:38 pm

we are using the RME sound card. I want design the card use the XMOS tech.

The xmos chip is certainly capable of everything you need
We are building a test system for pdm mics. so we need 700 - 3000KHZ , and the sample rate is not too bad for analyzing the mic performance.

Our IP for this is broadly:
- lib_mic_array which is a PDM to PCM block (cascaded FIR filters) but is optimised for 3MHz PDM clock. See https://www.xmos.com/support/libraries/lib_mic. You can see that it is a decimate by 8 followed by decimate by 4 followed by decimate by 2-12.
- sc_usb_audio which is a essentially a USB audio block.
I have study The XMOS for two months, can you give me some advice ?
I think it is imposible to me to re-design all of the filter stages, are you agree?

I am not familiar with your level of experience. If you look at lib_mic_array docs section 17.1 (fir_design.pyusage) you should get an idea how to modify it. You will need to understand FIR lowpass filters to do this. But it is certainly not impossible.
One other option is to modify things so that you input raw PDM (which is equivalent data rate of 96kHz 32b) into the host (which would be bit perfect) and do the decimation and filtering on the host. That could be a bit eaiser because you could use numpy scipy etc..
superganbu
New User
Posts: 3
Joined: Thu Dec 07, 2017 3:27 am

Postby superganbu » Sat May 26, 2018 2:40 am

One other option is to modify things so that you input raw PDM (which is equivalent data rate of 96kHz 32b) into the host (which would be bit perfect) and do the decimation and filtering on the host. That could be a bit eaiser because you could use numpy scipy etc..

Dear, I am interested in this method.
How many channels of raw PDM can the USB support and which XMOS lib can use?
Need I enumerate an another kind of USB Device or re-edit the report descriptor?
Which driver on PC?

Thank you very much.
User avatar
infiniteimprobability
XCore Legend
Posts: 1079
Joined: Thu May 27, 2010 10:08 am

Postby infiniteimprobability » Thu May 31, 2018 1:33 pm

We used something similar to this for capturing PDM in our test environment. It is not trivial though - the following needs to be considered:

- Bit perfect transfer of samples to the host only worked reliably up to 24b audio for some hosts. In the end we chose 16b audio. Obviously volume control needs to be disabled because this would mangle the data.
- The lib_mic_array front end needs to be replaced by a raw port capture loop
- There is a fair bit of data packing and unpacking to be done. The 8b port on lib_mic_array captures 8 PDM inputs and transfers 4 of them to the host in a 32b chunks, which gives a rate of 3.072 * 8 = 24.576Mbps.
- This then needs to be sent to the host in 16b chunks. We did this by packing it into a 16channel 96kHz 16b PCM stream (16 x 96000 x 16 = 24.576MHz)
- The max throughput is 64Mbps so actually you could only support 16 PDM mic capture at 3.072MHz.
- The host side then needs to unpack them all in reverse order.
- You then need to extract the individual bit streams out of the original PDM port capture
- The host then needs to do all of the PDM->PCM magic

This took quite a bit of work internally and lots of head scratching because of the data packing stages which can get a bit confusing. BUT, it does work and does allow bit perfect PDM capture for our test harness, although we only did it for 3.072MHz, 8 mics.

I could provide a little guidance but very limited support - you'd need to take on and understand the work involved.. it is certainly a few weeks worth even for a capable engineer.

Who is online

Users browsing this forum: Patriotwle and 25 guests