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:
- How many microphones do you need;
- 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:
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?
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.
