DSP with 8+ inputs for simple beamforming

Does anyone know of a DSP that is cheap and has 8+ inputs (8 I2s mics) and that can perform beam forming calculations? I'm super new to circuit design so preferably one thats beginner friendly.

Thanks

edit: We are students who were kind of thrown onto this project for a class with little prior experience and one of the requirements is more than 8 microphones.

Details on our actual school project: This is a sponsored senior design project, where a professor and one of his PhD students asked us to build a large (8+) microphone array that can be worn on a person's body. This array would collect data and store it in some data storage device that our sponsors can later access and run algorithms on. How we accomplish this was left open. The larger the array the better, our budget is unknown but likely $100-200 range. For our class we have to add additional requirements so we decided to attempt to use the data collected and run a beamforming algorithm on it to amplify noise in a particular direction relative to the person wearing the device. Essentially our demo would be someone wearing the device and pointing it at different sound sources and hearing the amplified audio through headphones. Essentially for the class we need to demo the device well but also build the device in such a way that our sponsors could use it for their own purposes after the class is over. We all have some 300 level DSP knowledge but it is all "textbook" knowledge and no hands-on hardware knowledge so we are attempting to learn it as we go. So far we have a microphone picked out here (ofc this can be changed) and are attempting to determine what DSP to use so that we can play additional parts of the device such as how we are going to transfer data to the headphones and data storage. It is also important to have some hardware component in the project which is why Arduinos and Raspberry Pi's are discouraged generally. • maybe something like the xCORE of XMOS? Still, fully agreeing with A_A, 8 channels and "new to design" is kind of contradicting. Feb 24, 2017 at 7:18 • I responded to some of this below to A_A, thanks for the response Feb 24, 2017 at 8:17 • "One of the requirements". You should at least post a synopsis of all of the requirements. It's really no use if you get twenty good answers and you'll have to reply to each one "I don't know, we'll probably not be allowed to do that". Especially if this is a class assignment, you should as a first step write down a clear requirements document! Feb 24, 2017 at 10:03 • that sounds like good advice, I'll edit it with the full requirements in an hour from now Feb 24, 2017 at 18:21 1 Answer 8+ high quality inputs for beamfroming and "...beginner friendly..." are competing requirements. There will soon be the audioinjector which attaches on Raspberry Pi and would be a relatively pain-free option for what you mention. You can program the Raspberry in a number of different ways including "low-level" C to high level Python or other. Another option would be to look for a multi-channel USB sound card which is Linux-friendly and attach it, again, to the Raspberry Pi (or small form factor pc). An older iteration of this one was just great for this purpose. And you get low noise amps, phantom power for mics and an internal DSP engine for basic preprocessing (although that was not accessible to the linux driver, at least a few years ago). This option again would give you the ability to program the multi-channel aspect via established hardware and software interfaces. Also, you might want to have a look at Jack and Portaudio. Hope this helps. EDIT: I appreciate the additional information. As it is in narrative form, I am going to try to unpick the requirements. You say (emphasis is mine): ...a professor and one of his PhD students asked us to build a large (8+) microphone array that can be worn on a person's body. This array would collect data and store it in some data storage device that our sponsors can later access and run algorithms on. How we accomplish this was left open. The larger the array the better, our budget is unknown but likely$100-200 range.

For our class we have to add additional requirements so we decided to attempt to use the data collected and run a beamforming algorithm on it to amplify noise in a particular direction relative to the person wearing the device. Essentially our demo would be someone wearing the device and pointing it at different sound sources and hearing the amplified audio through headphones.

You don't mention the most important element of the budget: Time.

I would strongly recommend to the team to read about beamforming and phased arrays. These concepts play an important role in determining the specifications of the system. In turn, the specifications of the system will determine if it is viable within the given resources (time, money, expertise, other).

An important aspect of this system is timing. If you take a closer look at the phased array concept, you will notice that direction of arrival depends on time of arrival of wavefronts at each receiver (microphone). Consequently, this means that two things on the array must be fixed: Sampling Frequency and Position.

If there is jitter in the sampling frequency, then the ability of the phased array to resolve between two nearby directions is reduced. Similarly, if the microphones are not fixed (worn on body), the end result will be the same.

Therefore, one key question to ask yourselves is: "What sort of angular resolution do we want the phased array to be able to resolve?". And by the sound of it, you have to think about this in two dimensions: One, rotation around the longitudinal axis of the body and two, elevation around the lateral axis of the body. The angular resolution will tell you:

1. How many microphones do you need;
2. What Sampling frequency to run them at.

Let's park this here for a minute and approach it from the other side:

You are going for a MEMS I2S Microphone, which is not a bad idea (on its own). Adafruit's library reads the microphone with 32 bits of precision (page 11), but the manufacturer of the SPH0645 says it has 18 bits of precision and it is read at frames of 24bits (page 3). Furthermore, the I2S bus, specifies that each data line can "carry" two channels. In fact, Adafruit's website mentions that it is possible to plug two of these mics on the same I2S bus but on different "channels" for stereo operation.

So, on the hardware side you have the following things to consider:

1. How are you going to simultaneously trigger the sampling of $$N_{mic} \ge 8$$ microphones if they are on at least 4 different I2S channels?

2. How are you going to transfer / handle the bandwidth of $$N_{mic} \times wordLength \times F_s$$ bits/sec to the CPU and process it? (Where wordLength is in bits, e.g. 24bit)

Point #1 Is extremely important because of the jitter mentioned above. Adafruit's code works with polling. In other words, you set up a counter that triggers an Interrupt Service Routine and within that routine you trigger a read on the I2S bus. If you trigger a read on the first I2S bus (channels 1,2) and after you are done with them, trigger a read on the second I2S bus (channels 3,4), the values that you read from the second bus are already in the future with respect to the values of the first.

So what?!?

Let's assume that you run your I2S at 4MHz. Ignoring the bus control signals, 24 bits of samples take approximately $$\frac{1}{4000000Hz} \times 24 \approx 0.000006 sec$$ (time to transmit both channels). This means that if you run your system at an $$F_s$$ of $$16kHz$$ then, in one period you can read at most $$\frac{\frac{1}{16000}}{0.000006} \approx 10$$ channels. But this is still pushing it, because the last two channels will be out of phase to the first two channels by about 1 period of $$F_s$$. Is this significant? It depends on your angular resolution and the sort of phase differences that you want to measure.

Now it is the turn of point #2 to start biting. We just spend about a period of the sampling frequency in reading data in from the I2S buses attached to our microphones. Who is going to do the processing? While the ISR is executing, the CPU is not doing anything else (it is assumed of course here that once you are in the sampling ISR, you turn off all other interrupt triggers).

So, somehow we have to make up time for the processing. How much time? I don't know, it depends on what you are trying to do (beamforming!). The simplest form of a phased array sums delayed versions of the signals from the microphones. This is not costly but if you want to do it in realtime you would have to read the two angles from the user. Which means that now, you have to get the CPU to read two pots (at least) on some analog input to determine where around the user is the main lobe pointing at. So, that's more time that has to be taken OUT of the processing and the reading data in.

Hold on!, didn't we say earlier that we are supposed to store the data to "...some storage device..."? So, this means more time to write the bits to the SD card, PLUS more time to handle the FAT Filesystem (at least), to be able to write to an SD card that is then plugged to a computer and it is possible to read files off of it.

Can you see the headache? At all times you are managing timing and bandwidth. In the end, you have a DSP CPU that can do very fast operations but you have it doing chores like "read a pot", "read a mic", etc.

So, forget about MEMS Mics on I2S buses and multiplexers. If you want to do this properly, you would design a "sound board" around a codec. For example this one, 24bit 6 channel in with max $$F_s$$ at 192kHz and I2S connection to the CPU. Its analog Input / Output section is built to accept Line-In levels which means that you can use simple capacitive mics with simple preamps. It operates on "frames" and it has buffered mode as well, so the CPU can now process a batch of samples in one go. Of course, now, you still have to solve the problem of storage and processing multi-channel streams.

But by the time that you are into designing a sound board around a codec, you are very close to using a sound card. Check out for example the "sound card" of the gumstix, it is just this codec but already plugged into the I2S of its ARM CPU, PLUS the drivers it needs to be accessible from within the Operating System.

This is why I suggested earlier that you do away with all of this by using off the shelf items. At least, you get all the "plumbing" for free and you can focus on developing the software part.

Hope this helps.

• Thanks, the help is much appreciated. My team was kind of thrown into this project for school with little say in the matter and one major requirement is greater than 8 microphones. Raspberry Pi's are only allowed to be used under special conditions so I may look into that. So from what I'm understanding, we need a development board to make full use of the DSP and your suggesting using the Raspberry Pi for this function? We were thinking of also using a DSP with low input and perhaps connecting the mics to a few mux's before the DSP to simulate having more input channels, with a separate clk Feb 24, 2017 at 8:17
• @pzhou07920 You are welcome. Can you please share some more specifications about this? It sounds very open and quite ambitious really. You have to deal with the multichannel analog IO, math libraries (fixed point, floating point) and finally the beamforming "math" (application specific). The CPU the Pi is using, does have DSP specific commands (see section 7.1). It might be doable on a "bare" DSP CPU but it depends on what exactly you are thinking of doing.
– A_A
Feb 24, 2017 at 8:47
• @A_A Offtopic, but the audioinjector looks awesome, thanks for the link!
– MBaz
Feb 24, 2017 at 17:53
• that sounds like good advice, I'll edit it with the full requirements in an hour from now Feb 24, 2017 at 18:21
• @pzhou07920 Thank you, I have edited the response. MBaz, it is indeed.
– A_A
Feb 25, 2017 at 2:03