things become a lot more complex if you try to sample real audio and try to elaborate it for other porpuses.
So very true!
Over the last couple years I've been working on an ambitious audio library for Teensy. It's pretty much an endless project, with more requests for ever-more-powerful features as more gets made. But all the basics and quite a number of fairly sophisticated things are already done pretty well.
Last year we made a nice hands-on workshop, and a 48 minute tutorial video.
As you can see if you watch the video, this is audio processing on a microcontroller implemented pretty well. Much of it depends on far more advanced hardware than you get with the low-end 8 bit AVR-based boards, but still, maybe it can serve as a reference for some of your questions about how to do audio sampling well?
Now, let's see if I can answer some of these specific questions.....
Except for the 10uF capacitor... what is exactly the reason why it has to be polarized?
Due to the physical properties of the oxide layer and electrolyte, the capacitor has a resistive conduction when the voltage is applied in reverse polarity.
You can think of capacitors are 2 parallel plates with an insulator between them. The capacitance goes up as the plates get larger, or as the distance between them gets smaller, or as the electrical permittivity of insulating the material between the plates goes up. In an overly generalized way of thinking about these things, as thinner, higher permittivity materials are used, trade-offs in performance come into play. When an extremely thin layer of oxidation is used as the insulating material, you get these polarity restrictions.
2- Quantization noise, according to my understanding, is something that you cannot avoid in ADC... anyway is something that can be reduced by simply increasing the sampling frequency, right?
Yes, this is called oversampling. Obviously it doesn't work for a perfect DC signal, since you'd read the exact same number every time. But for AC signals, oversampling can give you better results.
2 techniques are usually used to get the most out of oversampling. Filtering the results is the simplest to understand. A good digital filter algorithm can provide better performance than just averaging several numbers together (which is effectively a low-pass filter with poor performance).
Sigma-Delta modulation is the other technique commonly used with oversampling conversion. All ADC, DAC and codec chips meant for audio use this technique.
3- Aliasing and Nyquist, on the other hand, is something that I've studied more the 25 years ago... so I guess I'd better read something to recall what they exactly state! When you say "You also need to filter-out any frequencies above the Nyquist limit (half the sample rate) before digitizing", you mean that before the signal is read by an Analog Pin, the signal must be "low-passed" by a filter that cuts frequencies equal to 1/2 the sampling rate?
In practice, analog filters with steep roll-off are extremely difficult. They also tend to add distortion. Often for fairly low quality, little or no filtering is done and aliasing is allowed to corrupt the signal somewhat.
The beautiful think about massively oversampling with sigma-delta conversion is the Nyquist rate as far as low-pass filtering before the ADC is concerned is a few MHz, because it's sampling so very fast. That can capture a lot of ultrasonic signal, but it's removed by the digital filter within the converter. This, and good analog circuits without a huge digital processor on the chip silicon, are why external ADCs meant for audio give so much better sound quality.
4- About microcontroller programming: delay() does something different from setting a clock and so is not the correct way to define a sampling rate, understood! So I just have to rely on the sampling rate by defining the correct value of the ADC clock by means of commands like ADCSRA to prescale the ADC timers (this is not as user friendly programming as you can imagine for the common people, but I'll try to manage somehow) and whatelse?
If you want a reliable sample rate, you really do need to configure the ADC hardware to sample automatically, either free running or triggered by a hardware timer.
Can I simply analogRead(),
You can, but you'll have substantial sample rate jitter. Interrupts from the timers and serial and maybe other stuff cause small timing variations which cause analogRead() to sometimes make the measurements at the wrong moment, even if all the rest of your software has consistent timing (which is hard to achieve in practice).
Jitter is effectively noise on your signal. AC signals are always changing, so if you measure at the wrong moment, you get a slight different number. That's noise, even if your ADC has perfect accuracy, simply because it was used at the wrong time.
send the read value over the serial() to the USB link and do my elaboration of the sampled raw audio on my PC?
Well, that depends. Some boards like Arduino Uno have real serial and a chip with acts as a USB to serial converter. On those, you're limited by the serial baud rate. Because of start and stop bits, every byte takes 10 bit times. If you use 115200 baud, the most you can transmit (if everything works out perfectly) is 11520 bytes/sec.
Other boards have native USB. On those, the baud rate setting is ignored. The USB native bitrate is used (12 or 480 Mbit/sec). The actual data throughput depends on a lot of complex software factors, which usually boil down to how efficiently the code on both the board and your PC are written.
Is the serial() function somehow affected by the changes of the processor clock?
Yes, but the functions you use attempt to make everything "just work", regardless of the CPU clock.