More accurate MCLK generation
This change generates MCLK at exactly 44.100 kHz for almost all possible CPU frequencies. The previous MCLK clock was generated at 44.117 kHz which was above the maximum USB supply rate for Mac computers.
This does not help - the 44117 were intended, because of ADC/DAC
Could you elaborate a bit more on why this frequency was chosen? Why does the SGTL5000 (for example) need to run at 44117? Also 17Hz is audibly perceptible meaning that music played through the Teensy will sound higher pitched than intended.
All the audio library objects need to run in perfect sync, to allow you to interconnect them in any way with the design tool.
The ADC and DAC use the PDB timer, which can only be programmed for periods that are an integer division of F_BUS. Likewise, the PWM output needs to also be an integer division F_BUS, due to the way the FTM timers work. These peripherals don't have any option to both multiply and divide. They only support integer division, and only from F_BUS, which itself must be an integer division (between 1 to 8) of F_CPU.
Normally F_BUS is 48 or 60 MHz. At 48 MHz, we divide by 1088, which gives 44.117647 kHz. At 60 MHz, we divide by 1360.
Also 17Hz is audibly perceptible meaning that music played through the Teensy will sound higher pitched than intended.
Just to keep things in perspective, this error is 0.04%. It won't ever be 17 Hz sound error, since the maximum (nyquist) frequency we can represent is only half the sample rate, so it can be at most 8.5 Hz off for a dog whistle. When playing note A4, which should normally be 440 Hz, the result will be 440.176 Hz. That is indeed slightly out of tune, by not quite 1 cent (0.0578%). In fact, it's 0.7 cents off. My understanding is the threshold of human tone/tuning recognition is about 5 to 6 cents.
Remember, we're running on a low power microcontroller and trying to provide a large music & sound feature set. I would very much like everything to be technically perfect, but with such limited hardware some compromises have to be made.
Thanks for clarifying Paul. Did you see my email to the Apple engineer regarding this issue?
Yes. This Friday I'm going to try to pick up a Macbook Air (hopefully a black Friday discount), since my only readily available Mac for testing has 10.7.5 and I'm intentionally not upgrading so I can build releases compatible all the way back to 10.6. I really want to do this audio testing with the latest Sierra.
Maybe it's not the 17 Hz difference? Will try the closer sample rate and some other stuff. But this is on a long list of stuff I need to look into. Next up before Friday is the optimized Adafruit ST7735 library, which apparently isn't working with some newer ST7735 variants and needs to be updated.