I hope Paul Stoffregen will see this.
Yup, I see this.
First, please understand the Audio library and most other libs are in a sort of "feature freeze" at the moment, while most dev work is going into the new Teensy. I'm sure you've seen the beta test thread here on the forum.
Two changes to the library would open it up wide for folks doing teaching and science. One is to use the full 3.3V swing.
I had intended to put this into the code some time ago, but never got around to it. So far, the 1.2V range as worked very well for most people.
The other point to consider about 3.3V range is you're using the power supply as the voltage reference. Teensy 3.x has some VREF filtering for the worst high frequency noise, but in the audio band any noise on the supply can easily couple into the ADC this way. The built-in ADC is already pretty noisy, so I'm a little skeptical this is necessarily a step in the right direction. Nonetheless, when work resumes on this and other libs, adding the ability to change the reference
like we have for the built in DAC output (right-side documentation panel) isn't that difficult.
The second would be allowing the user to modify the sampling rate. This would be super helpful.
This is unlikely to ever happen on Teensy 3.x, at least as a convenient API provided by the library, because the hardware simply isn't that flexible. Especially the PDB timer used for the built in peripherals offers only integer divisions of F_BUS, which is itself an integer division F_CPU. Between the different Teensy models and different clock speeds available, and the requirement for all the master-mode I/O to run exactly synchronous to the clock (where the other stuff runs from mult+div of MCLK), the result is only certain sample rates are possible.
When we have Teensy 4.0, the technical trade-offs will be different. There we get a PLL dedicated to the audio, and peripherals that can run asynchronous from the CPU clock. M7 at 600 MHz also offers much more capability for retiming / resampling in the cases where we need to deal with slightly mismatched rates. I always resisted doing this on Teensy 3.x... but after so much pain with various USB hosts doing USB audio differently, I believe that is probably going to be the best long-term solution for USB, maybe SPDIF input too? If you check out the beta test thread, you can probably see we're still quite a ways off from getting to these sorts of very fine details, but you can also see progress is coming along quickly. I imagine we'll be in a good position to really consider these sorts of major structural changes around the middle of summer 2019.