1

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?

JYelton
  • 32,302
  • 33
  • 134
  • 249
user1584421
  • 1,259
  • 2
  • 17
  • 32
  • 2
    Audio is not that high-speed an application. – Ignacio Vazquez-Abrams May 14 '14 at 13:36
  • 6
    why is this question tagged 'arduino'? – Vladimir Cravero May 14 '14 at 13:43
  • Existing project to do this found with a few seconds of googling: http://www.adafruit.com/blog/2009/07/07/waverp-an-arduino-library-for-recording-and-playing-wave-files-on-the-adafruit-wave-shield/ – pjc50 May 14 '14 at 14:15
  • .. and MP3 encoder IC: http://www.vlsi.fi/fi/products/vs1063.html – pjc50 May 14 '14 at 14:16
  • @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. – Chris Stratton May 14 '14 at 15:22

1 Answers1

4

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.

Olin Lathrop
  • 310,974
  • 36
  • 428
  • 915
  • 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. – Chris Stratton May 14 '14 at 15:24
  • 1
    @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. – Olin Lathrop May 14 '14 at 15:29
  • 1
    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. – Chris Stratton May 14 '14 at 15:33