You are likely to need a lot more functionality than an ADC. IMHO choosing an ADC isn't a very useful place to start.
Until you understand the problem adequately, choosing a separate ADC or DAC is likely irrelevant. IMHO it is fretting over details, which may never matter, before there is enough experience and understanding of the overall problem.
Think about the overall problem. Break it into pieces. Start with the pieces that both contribute progress and are easiest to test and debug. In your problem, that is the digital to analogue output, and not analogue to digital input.
I've made a SWAG about the end-to-end problem, and considering your
I want to make it digital as a challenge (and in case I want to add more terminals in the future, control it with an arduino, or whatever)
it is likely that it'll need:
- microphone into an ADC
- a way to encode and send the sound-data, probably as a serial stream of bits (to avoid funky or expensive cabling between floors of your house),
- receive the serial stream of sound-data bits
- decode the sound-data and
- convert back to analogue and drive a speaker.
If you have access to a ready made analogue audio amplifier and speaker, you could start with the DAC problem. (The amplifier and speakers should be cheap as things can go wrong)
I'd start with an off-the-shelf microcontroller development board. Many microcontrollers have all the digital functionality (ADC, DAC communications), but will need analogue microphone input and speaker output. One with a DAC should be able to drive an audio amp, maybe with a few resistors or potentiometer to set volume. Once this is tested and done, you can move on.
Summary: Solve the analogue output problem first.
Further, I might not start at the microphone end. A problem with starting with the microphone and ADC is how to test it. It is unlikely to work first time. So there needs to be a way to extract the ADC data, and then some way to check the data is okay. An easy way to check the data would be to convert it back to analogue and play it out of a speaker, or convert to analogue and display it, along with the original signal, on an oscilloscope.
The point is, getting the output working before starting on the ADC gives a way to test the ADC input. Building pieces in a different order makes testing harder and IMHO less fun.
With a PC, and a spreadsheet or the ability to program, sample data for the output could be generated and stored in a program as data (an initialised array containing values for eg a sine wave, or even voice eg. from wikipedia).
Summary: build the pieces in an order which is easy to test without needing all of the parts to work.
Maybe an Arduino? It has lots of helpful examples with code, free, Open Source development software, documentation and community. It has a built in ADC, and serial interface, and with a bit of ingenuity can do an okay-ish job of DAC.
An Arduino UNO is not ideal for audio, but could just about do voice. It's built-in ADC is only 9615 samples/second, which isn't quick enough for reasonable quality music. It's ADC is a rate comparable to telephone land-line (8k sps). AFAIK, land-line's audio is filtered to be 200Hz-3kHz-ish and is okay for voice (I assume the telephone's 8-bit 'Mu-law' encoding may be comparable to the Arduino's linear 10-bit sample quality).
An Arduino M0 might be a better option for a wired system. It has a 12-bit ADC at 350ksps, and 10-bit 350ksps Digital-to-Analog Converter (DAC).
If you have software development experience, another option is an ARM mbed development board (ST make some under $10). Some of them have much better ADC than an Arduino, and real DAC, as well as multiple serial ports if you want to extend things.
Some of the low-cost ST mbed boards have MCU's capable of 500x faster sampling (5msps) than an Arduino, and at 12 bits. That extra bandwidth would enable higher quality and simpler electronics to filter the microphone input signal.
As @crj11 says an ESP32 is a plausible option. It has ADC, DAC, WiFi, and multiple (wired) serial ports. It also has a 'plug-in' for the Arduino environment, and some examples to get you started.
If you shop around on one of the popular (Chinese) shopping sites, you might find ESP32 development boards which have a microphone and speaker amplifier built in.
AFAIK the ESP32 ADC is about 50k sps, so usefully better than the Arduino. However, some of the ESP32 development boards have external ADC chips, and even audio codecs, though they might be a lot more development effort to use, and restrict your choices of development board.
As @crj11 commented an advantage of using ESP32/ESP8266 would be doing it without wires. Avoiding the cost and hassle of wiring might be the 'killer' feature. With WiFi one end of the system might be an existing computer, which may be interesting and even fun.
You could probably get an ADC and a DAC which uses the same basic protocol. The one you identified (MCP3201) can use SPI, and there are DACs which use SPI too.
However SPI has a 'master' and a 'slave' [see Role note below], and ADCs and DACs are usually 'slaves', not 'masters', so the 'master' functionality missing.
The 'master' decides when to access the 'slave', and the 'master' generates (at least) clock signals to drive the slave. Common external ADC and DAC devices are 'slaves'. So they can't simply be wired 'back-to-back'. Something else needs to act as a 'master'.
Further, there may be buffering in the ADC or DAC which needs to be triggered by extra signals before or after the right number of clock signals. So a microcontroller is likely in the system just to drive the signals for an external ADC and DAC.
Also, not connecting the ADC directly to the DAC offers valuable flexibility.
First, the ADC and DAC don't need to match in bit-width, bit order, or detailed implementation of the protocol. So there are a lot more options, and they could be chosen based on cost, functionality, convenience, etc. unconstrained by needing to be directly connected electrically.
More usefully, testing the DAC and analogue output is independent of testing the ADC and analogue input.
Further the ADC and DAC don't need to run at the same data rate. So some of the task of filtering the input signal might be made easier by running the ADC at a different sample rate than the DAC.
Summary: there will probably be a microcontroller acting as a controller and intermediary even if there is an external ADC and DAC.
[Role]: SPI master/slave roles can change between transfer transactions, ie. any device might sometimes be the master and sometimes the slave. However for each transaction one device is the master and the other the slave.