I want to process the signals of five electret condenser microphones with raspberry pi and i since the RPI has no audio inputs im thinking of using a sound card.
Im looking for a sound card with five simultanious inputs in order to do synchronized sampling, im thinking of using the Wolfson Raspberry Pi Soundcard, is it capable of achieving what i intend to do?
If the wolfson sound card is not capable of that, is it possible to do that with the MCP3008 ADC?
h raspberry pi and i since the RPI has no audio inputs
synchronized sampling, im thinking of using the Wolfson
hat with the MCP3008 ADC?
i need the GPIO to control two servo motors, the rest of the pins is dedica ted to the other part of my project which is processing the mics signals. W hat i understood from your post is that i only have one way to acheive that by using the MCP3008, am i right?
On a sunny day (Wed, 27 Aug 2014 09:43:04 -0700 (PDT)) it happened Tareq Matar wrote in :
One way ... I dunno, there could be a thousand ways. but that wolfson soundcard (I looked up the datasheet) covers your GPIO connector, so that seems a nono. That leaves your proposition of the MCP chip. But here are many other AD converters. If 10 bits is enouhg go for it. You still need to write the software. Audio needs exact timing.
On a sunny day (Wed, 27 Aug 2014 15:56:45 -0700 (PDT)) it happened Tareq Matar wrote in :
Maybe I would simply use a PIC:
formatting link
digitizing one or more audio channels should be no problem, and sending the data via a ultra high speed link (SPI, RS232 logic level, I2C or whatever, own protocol) to the raspi should not be that hard. Maybe I would not need raspi at all, use multiple PICs. But hey I am not doing that design, so .. Homework. But it is all about timing. I have not done any audio driver coding for the raspi, but you need to work with interrupts, write a kernel driver. Have you ever written a Linux kernel driver?
To prevent that sort of things in my raspi based DVB-S transmitter by using a hardware FIFO, to get a precise steady timed stream.
formatting link
For audio you would need more bits... for more than one channel more depth (memory). I have no idea what you can do hardware and software wise. Its up to you, that adventure.
you gave me an idea so thank you, in my project some kind of buffering is needed and i had no idea how to do that and FIFO is the answer. Did you use it in your DVB-S transmitter to buffer data and to get a precise steady timed stream?
On a sunny day (Fri, 29 Aug 2014 11:31:35 -0700 (PDT)) it happened Tareq Matar wrote in :
Yes, in the DVB-S transmitter (but there it is data out, in your application it would be data in), I use the FIFO to make a steady stream, clocked by either a crystal oscillator, or the Raspberry Pi's internal PLL.
The problem with Linux (and any multitasking operating system) is that tasks (programs) are executed sequentially (say 'in turn'). The effect of this is that every so many milliseconds YOUR program is interrupted. For video and audio this is not acceptable as you want to sample the audio (in your case) with exactly say 48000 samples per second (or whatever you need, 8000 would be enough if you only want 3.4 kHz maximum frequency in audio),
The Linux kernel uses interrupts and keeps a buffer in RAM. Programs like OSS and ALSA write to this buffer, and the kernel driver makes sure the samples are send on time. You could look at some kernel drivers to see how this is coded.
But part of the raspi hardware (that Broadcom processor) is closed source, I have not tried writing a kernel driver for it yet. And also I did not want to be locked into some specific thing like a Raspberry Pi, so that is why the buffer FIFO seemed so much simpler, I could even use the PC par port to drive the DVB-S transmitter I think.
Your hardware would need to sample the ADC, put the byte in the FIFO, and signal the Pi there is data, you need to calculate (or measure, estimate) how much time Pi will be 'away' doing other tasks (in my case a few ms) and that sets the size of the FIFO.
That is why I was thinking PIC, as a PIC can then also generate the clock and sample commands for the ADCs (or SPI or whatever you use). And PIC has multiple analog inputs.
On a sunny day (Sat, 30 Aug 2014 05:44:13 GMT) it happened Jan Panteltje wrote in :
PS To do it right you also need, for every channel, an anti-alias filter (lowpass). Say you want to sample at 8 kHz, then a 3.4 kHz low pass is required in the mike channel to prevent any frequency equal or higher than 4 kHz (8000 / 2) to reach the ADC. I have done that in the past with just opamps. Look here:
formatting link
That is very very old (eighties), also note the sample and hold before the ADC, and the generation of the sample pulse. PICs have sample and hold ciruit build in and timing can be set in software.
On a sunny day (Sat, 30 Aug 2014 06:53:47 GMT) it happened Jan Panteltje wrote in :
PS2 Probably you could oversample by a lot, and then use digital filtering, as to make a precise lowpass with analog components where the phase has to be the same for all your channels may require very high precision components, That is why I mentioned multiple PICs (say each one sampling at 100 kHz with software lowpass). And maybe for your application the aliasing does not matter? Not sure. FPGA with multiple ADCs could work too. FPGAs usually have some on board RAM that can be used as FIFO too. I do not know how the audiophile data acquisition systems work these days, if you use their chips things may be easier.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.