Some good ideas here :)

I used the Atmega328 for a GPS and acceleration logger and the bursty behavior of the SD write became the biggest problem. So I do know about that problem, the Tensy would certainly solve that but it felt so overkill with 21 inputs (check that again its 21 pins but only 2 converters for 3.1 and 1 for 3.0 so maybe not so much overkill as I though before). But really the dream scenario would be a micro controller with high quality input (why not 24-bit 96 kHz or higher sample rate?) that just feeds a SD card over 4-bit SDIO, would reduce the burstyness if I understand it correctly. But SDIO support doesn't seem to be supported on weaker micro controllers.

Maybe its better to use a esp8622 for reading the SPI from the ADC and then send that data to a central unit with the SD card that logs all the channels simultaneously... (I do want to be able to have several of these out logging).

https://github.com/PaulStoffregen/Audio/tree/master/examples/Recorder

Looks like an easy solution for the problem. Its approximately the level I know about at the moment and would implement if I had to do it now right away. Im mostly curious with the stack question if there exists something even more bare bone and downscaled to a minimum as I only want a record button and then read the analog signal and dump it on the SD card. But seams like that doesn't exists.

yeah its pretty specific, i can't say i've seen such an IC but adc+cpu+sdcard is about as simple as it gets, you might find a SOC with it, but 48kHz 16 bit audio and an actual 16 bit ADC is a pretty tall order. the spi->sdcard is going to be tricky at those speeds, unless you only want a short sample buffer.

I'm the author of that library and example!   :)

If you can live with the lower quality of the built-in ADC, it's pretty simple to replace the AudioInputI2S object with the AudioInputAnalog object, and delete everything related to controlling the SGTL5000 chip.  Delete the lines that reconfigure the SPI pins, if your SD card is connected to the normal 11, 12, 13 pins.  Then you've got a solution that's just the Teensy 3.1 and SD card.  Or you can make your own PCB with just the MK20 chip and SD card, and program the .HEX file from Arduino onto the MK20 chip.

maybe #audioThing - ephemeralEventRecorder from @esot.eric.wazhung?

hah! Thanks for the shout-out :)

If 12bit were enough, this job could be done with a PIC18F2553. I prefere JALv2 as Programming language.

Writing to the SD card is bursty -- you send data, issue the write command, and then wait until it's done.  Meanwhile you're still getting audio (in your case) data in, so you've gotta buffer it a little bit. That's where a microcontroller comes in handy.  

Here's what I'd want for the micro: 2xSPI busses (assuming an SPI ADC), DMA routing capabilities, and enough RAM in between to buffer a little bit.  (DMA is essentially what you're asking for above -- taking the ADC data in and dumping it right back out to the SD card.)

You could make it work with any ARM chip except the absolute bare-bones M0+ types which lack DMA or enough RAM.  The ARM M4 in the Teensy 3.1 will handle it easily.  

If you can stand 12-bit audio, you could use the built-in ADCs, which would greatly simply everything.   You might start there first and then add in an offboard ADC later.

I've built a similar DAQ device that dumps values from an ADC to an SD card directly using an atmega 328, but it only samples at 80hz due to the limits of the ADC.

At 16-bit/48 kS/s (768kb/s) you would be above the sampling limit for SPI and I2C on the atmega 328. You might be able to get by with an ADC with a parallel output (1 IO line per bit), but it'd be difficult to keep up with that sampling rate while dealing with the SD card as well. Using an ARM I doubt you'd have any issues. So, I would suggest a Teensy 3.0 for initial development. It has a built in ADC, but not quite fast enough to get what you are looking for. Sampling an external ADC on the other hand should be no problem at all.