[quote author=Paul Stoffregen link=msg=2636838 date=1456622768] Tim, will this create inaccurate (lower) frequencies if a significant number of interrupts occur during the delayMicroseconds() calls?
For example, someone could use Serial.print() right before calling TimerFreeTone(). Or they could have another library like Servo or FreqMeasure running, which is constantly servicing interrupts from the timers. In fact, if they need this timer-free code, it's a safe bet they probably have a project already doing something useful with all the timers, which often involves interrupts.
Wouldn't it be better to read micro() at the beginning, and then in busy loops for the delays, so you can automatically adapt to interrupts consuming CPU time? [/quote]
That may work better in certain conditions for sure, but with additional overhead. This library is by no means accurate in frequency nor duration if there's a lot of other interrupts happening. I guess it's designed to simply "work" but with the understanding that accuracy is out.
I would use this library for simple "beep" indications when all timers are used. Not really good no matter how the duration is calculated if the user is trying to play a melody while other interrupts are triggering. The length may be a bit more accurate with your suggestion, but the frequency will still be off.