If I am correct, I believe that all normal audio jacks (like the ones you have to your PC, traveling to your speakers) are analog.

Is there a way (perhaps with a high speed ADC) to convert it to digital on the fly? I am considering a project with Arduino (perhaps) where you capture audio in digital form and store it in an SD card.

Then of course, this will be just a sequence of bits. So is my project bound to failure because of the heavy volume of data? Or perhaps the information won't even make sense because it won't be equivalent with any audio format? Or essentially, it will be a WAV file (without the header)?

Finally, is there something like an analog to digital encoded (MP3 or whatever) hardware encoder?

  • 2
    \$\begingroup\$ Audio is not that high-speed an application. \$\endgroup\$ Commented May 14, 2014 at 13:36
  • 6
    \$\begingroup\$ why is this question tagged 'arduino'? \$\endgroup\$ Commented May 14, 2014 at 13:43
  • \$\begingroup\$ Existing project to do this found with a few seconds of googling: adafruit.com/blog/2009/07/07/… \$\endgroup\$
    – pjc50
    Commented May 14, 2014 at 14:15
  • \$\begingroup\$ .. and MP3 encoder IC: vlsi.fi/fi/products/vs1063.html \$\endgroup\$
    – pjc50
    Commented May 14, 2014 at 14:16
  • \$\begingroup\$ @VladimirCravero - because the poster mentions they are considering using an Arduino as the platform, and that's an important thing to mention because it lets us point out that a (standard ATmega-based) Arduino is a poor choice for this application - its onboard ADC is only capable of low quality audio, it has limited RAM for buffering, and it's going to be fairly busy servicing data from an external ADC. \$\endgroup\$ Commented May 14, 2014 at 15:22

1 Answer 1


Audio is not that high bandwidth, so is within the range of what a microcontroller can handle.

The quality level you want makes a large difference in the amount of data you have to handle. If you just need to save and later replay voice, then 8 bit samples at 8 kHz is good enough. If the 8 bit values are not constrained to be linear, then you can get better overall signal to noise ratio with the same amount of data. This is what the phone company does.

At the other end is "Hi-Fi" audio, which is from 20 Hz to 20 kHz, usually at least 16 bits per sample (over 90 dB signal to noise ratio). To digitize such audio, you sample much faster than the Nyquist limit, then apply digital filtering, then dessimation. The reason you need digital filtering is that analog filtering can't be that accurate to have the very sharp drop off after 20 kHz you need in order to sample just a little faster than 40 kHz.

Let's say you do the worst case and end up with 16 bit samples at 44 kHz rate. That's only 88 kB/s, or 5.3 MB/minute. Any SD card can handle that data rate. 1 GB gives you over 3 hours of this Hi-Fi audio.

Of course if you just want the voice-quality audio, things are much easier, the data rates lower, and the storage requirements lower. At 8 kB/s just 1 MB lasts over 2 minutes. 1 GB would hold nearly 1 1/2 days of audio.

  • \$\begingroup\$ An SD card may be able to handle the data rate on average; but I'm not as certain it can do so smoothly without delays, and as a standard Arduino has only 2K of RAM it will be highly sensitive to any write delays. It may be that it does work in practice. \$\endgroup\$ Commented May 14, 2014 at 15:24
  • 1
    \$\begingroup\$ @Chris: My answer was about the general theory and background on digitized audio. Trying to do this with a arduino is likely inappropriate, but the OP should be able to tell that for himself once he decides what kind of audio he wants and then gets the bandwidth requirements from my answer. For high data rate, you want something that can buffer one whole write block, however big that is. A small micro should be able to handle the low data rate of voice audio. Again, we need to know what kind of audio the OP has in mind. \$\endgroup\$ Commented May 14, 2014 at 15:29
  • 1
    \$\begingroup\$ Yes, you covered much of the problem well. What I was adding was the specific distinction between average data rate, and instantaneous rate, and resulting buffer requirement. It's one of those gotchas newer designers such as the poster may be can easily overlook. \$\endgroup\$ Commented May 14, 2014 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.