I don't have any questions about specific devices but I'm curious about different possible approaches to audio input and output to/from the Arduino. I can think of a few theoretical possibilities but I don't have a very good grasp of the technical issues and what limitations are involved.
Audio directly to/from Arduino -
An 8 bit ADC on the digital ins and an 8 bit DAC on the digital outs would allow 8 bit audio to be passed through the arduino right? I realize that the arduino doesn't have the power to do much with the data but I don't quite understand how to figure out what it can handle. Would it be possible to send two audio streams through the arduino and switch between them or add them together? Is there a way to roughly calculate what it can handle? I don't understand the relationship between the chip's clock speed and the audio's bit depth and sample rate. Obviously the chip's clock needs to be faster than the sample rate but does that mean that it can theoretically handle (clock speed divided by sample rate) number of audio streams?
Arduino controls a dedicated audio chip -
Are there are off the shelf dsp chips that the arduino can easily control? I'd imagine that this would allow for higher sample rates and bit depth plus more flexibility at the cost of more expensive hardware and possibly some custom dsp code. Does the Arduino's speed limit how much can be done? Is the arduino even necessary in such a situation? I guess it would handle the hardware interface and other non-dsp tasks. This route is probably beyond somebody who is asking the kind of dumb questions I'm asking right?
Arduino reading audio from memory -
If sound input isn't required, would it be possible to have the Arduino interface with some kind of memory that's pre-programmed with the audio data? Then it just reads it out to a DAC. I believe I read that some older devices used to multiplex multiple low bit dacs to get higher bitrates. Would an approach like this be possible to get 16 bit output from the Arduino with two 8 bit DACs? Or can the arduino drive a 16 bit dac directly and I'm misunderstanding the relationship between the chip's 8 bit architecture and the audio's bit depth?
I think you would be OK doing ADC to Arduino audio detection, and also DAC Arduino to sound generation, albeit crude.
I'd forget about using the Arduino to pass through the data and process it-- it isn't fast enough and the code will not be compact enough.
this is not meant to be a DSP, it's a programmable controller, so think of it as something to send control signals and you will be fine. There are more elegant design solutions for digital audio.
D
Thanks for the reply. Why isn't the arduino fast enough to simply pass audio through, reading it from an ADC and writing it directly to a DAC? Wouldn't 8 bit 22khz audio simply be a string of 8 bit numbers running along at 22khz and the arduino is running much faster at 1mhz? Or am I completely misunderstanding the issue?
And by ADC to arduino audio detection do you mean something like the piezo knock sensor idea on the playground where you're simply sensing the input go over a certain threshold? Or do you think it might be possible to turn an audio rate signal into a usable control signal?
I think you could do a fair amount of pass-through and simple processing of audio with an arduino. As you say, 22k samples/second at 16MHz CPU speed gives you something like 700 instructions to "process" each sample. Note that in general, both reading and writing analog data is going to be more than a single instruction, and "real" audio algorithms like digital filtering end up taking a very large number of cycles to implement (and perhaps lots of memory as well), but I bet you could do a pretty good job of (for example) recording audino to a serial flash chip or card, introducing distortion, etc; the sort of things people used to do with simple electronics cleverly used to make guitar effects devices, for example. Compressing the audio using a modern scheme like mp3 is probably out of the question, though.
Note that in general, both reading and writing analog data is going to be more than a single instruction,
I wasn't thinking about that. Would the incoming audio have to be written into some kind of buffer and then read back out? I sort of think of audio as just acting like an analogRead on a knob that's turning very very fast But I guess it's probably much more complicated than that.
and "real" audio algorithms like digital filtering end up taking a very large number of cycles to implement (and perhaps lots of memory as well), but I bet you could do a pretty good job of (for example) recording arduino to a serial flash chip or card, introducing distortion, etc; the sort of things people used to do with simple electronics cleverly used to make guitar effects devices, for example. Compressing the audio using a modern scheme like mp3 is probably out of the question, though.
Yeah, I wasn't hoping to do any real dsp like filtering or mp3 compression. More like using the audio to effect control signals with primitive envelope following or things like that.
both reading and writing analog data is going to be more than a single instruction,
I wasn't thinking about that. Would the incoming audio have to be written into some kind of buffer and then read back out? I sort of think of audio as just acting like an analogRead on a knob that's turning very very fast But I guess it's probably much more complicated than that.
I wouldn't say that it's MUCH more complicated than that, but have you looked at the code underneath "analogRead" to get an idea of its complexity? Typically you tweak a bit to start a conversion, wait for the conversion to finish, read the data, and then set a timer for the next time you want to sample the input. If you have an external converter, this probably happens over some sort of communications channel that may require additional bit-twiddling to talk to. None of it is really "hard", but it all takes instructions, and the whole process is "hard" real-time; start taking a little bit too long SOME of the time and the results will suck.
I haven't actually looked at the underlying code for analogRead but it makes sense that the code would be similar in principle to what would be required for an external ADC. Thanks for the help!
