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!
16 or 24 mic(PDM) to PC as a sound card
-
- Member++
- Posts: 21
- Joined: Thu Dec 07, 2017 3:27 am
-
Verified
- XCore Legend
- Posts: 1156
- Joined: Thu May 27, 2010 10:08 am
Dears,
Why not just design a single card with 24 mics? It is possible with a 4 tile device.
You will need audio class 2 drivers for that many channels, but Windows 10 has those built in now.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.
Probably not, unless you are not too worried about synchronisation.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)
Why not just design a single card with 24 mics? It is possible with a 4 tile device.
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.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?
Engineer at XMOS
-
- Member++
- Posts: 21
- Joined: Thu Dec 07, 2017 3:27 am
The 4 tile device is OK.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.
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?
we are using the RME sound card. I want design the card use the XMOS tech.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 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
-
Verified
- XCore Legend
- Posts: 1156
- Joined: Thu May 27, 2010 10:08 am
The xmos chip is certainly capable of everything you needwe are using the RME sound card. I want design the card use the XMOS tech.
Our IP for this is broadly: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.
- 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 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.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?
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..
Engineer at XMOS
-
- Member++
- Posts: 21
- Joined: Thu Dec 07, 2017 3:27 am
Dear, I am interested in this method.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..
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.
-
Verified
- XCore Legend
- Posts: 1156
- Joined: Thu May 27, 2010 10:08 am
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.
- 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.
Engineer at XMOS