Hillcres-Hellio:
My last piece of experimental music:
Nice whistlings ha ha 
About the recording, the audio actually sounds like it is supposed to (as the header and encoding is concerned); the annoyance comes from a loud pulsing noise that mixes with the microphone's signal.
That pulsing noise is the SCK line of the SPI port; mostly when it has to update data blocks (otherwise a 4 or 8 MHz clock frequency should not be audible for any non-ultrasonic equipment or human being).
The solution sounds bizarre: you have to kind of isolate the ground line for the microphone's output (or the SD card). I said "kind of" because is not literally cutting off the ground connections.
I'll let someone else give you more details about this solution, since for me is hard to explain (being honest, I've never applied that on a similar problem I'm having, because I actually don't understand how to either)
DVDdoug:
Somewhere, I read about write-speed limits with SD cards but I don't think that's true. I've got a video recorder that records to an SD card.
The limit comes mostly from the microcontroller's available RAM and the SPI clock speed. Interacting with the native SDIO protocol rather than ("legacy") SPI, is less than an issue.
A test I've made long ago, I noticed that an ATmega328P at 16 MHz can write at approx. 53 KB/s; being a for loop the only known significant overhead. Maybe I could push 1 or 2 KB/s more if I disable the timer0 overflow interrupt (that makes delay(), millis() and micros() possible).
You may judge if less than 53 KB/s is enough for the application.
DVDdoug:
The ADC is 10-bits, so you could write it into a 16-bit word, and then bit-shift to get full-volume.
I know it's the only way to record the whole resolution, but is not true 16-bit audio nonetheless.
DVDdoug:
Stereo is possible, but since there is one-shared ADC you can't sample left & right a exactly the same time. And, the ADC speed-limitation is also "shared" so you'd have to cut the sample rate in half.
Aside from the sampling rate, the shifted timing of both channels is for me the deal-breaker in stereo capabilities.
DVDdoug:
I don't think "processing" is the limitation/bottleneck.
However:
DVDdoug:
8-bit WAV files use unsigned integers, whereas everything else uses signed integers
Remember that the ADC also spits out unsigned values, and converting to a two-complement (signed integer) encoding (by substraction) takes up several CPU clock cycles; even more when it's 8-bits "wide".
Endianness is not a problem; the RIFF/WAVE standard always expects little-endian (LSB first), while the Arduino also encodes the variables (int and larger) this way.
DVDdoug:
P.S.
You know... In theory recording is "easy", especially at 8-bits... You just read the data at a known sample rate and write it to a file. (With a 10-bit ADC you have to right-shift two bits before throwing-away the high-byte of a 16-bit integer.)
The only tricky thing is writing the header, but that's not too bad if you're always writing the same format. And, you do have to go-back and write the data-chunk size when you stop recording.
This is what the library does. The only aspect you missed is the double buffering necessary to keep sampling even when writting to the card.
TMRpcm does even more complicated stuff to keep the process out of the main code: it uses the input capture register (ICR) to define the sampling rate (triggers the sampler ISR), and one of the output compare registers (OCR) to trigger the ISR that writes to the file if one of the buffers is full.
In order to avoid delays in the sampling, this ISR re-enables only the overflow interrupt (triggered by the ICR); hoping that the full buffer gets completely written before the other one gets full as well. This is why is so important to not choose a very high sample rate.
A similar thing does when playing, although buffer overruns are more unlikely since reading is faster than writting. 44100 Hz playback is still not possible, but this time you can blame the external oscillator; at 16 MHz clock and 8-bit PWM resolution, the maximum frequency it can achieve is 62.5 KHz (fast PWM). For 44 KHz playback, you need at least close to 100 KHz of PWM; and so a faster microcontroller or a real DAC (a resistor ladder on pins 0 to 7, aka port D, should work too).
Yeah, not an intuitive explaination for beginners; but... this is the "magic" behind the library nonetheless.
DVDdoug:
...Playback is not so easy when you don't have a DAC. 
From a certain sampling rate it's true, otherwise PWM is a feasible alternative.
DVDdoug:
And, it's more like a couple cm's at "Arduino sample clock rates".
Maybe the "drag" will become larger if you consider how the ADC in a AVR works. You know, successive approximation takes a while.
