On top of all these other issues, you're probably going to encounter problems due to limitations in Arduino's tone() function.
The main issue is calling tone() instantly reconfigures the hardware timer. At least the tone() implementation currently in Arduino's core library for AVR does this. Arduino Zero (Atmel SAMD), Arduino Due (Atmel SAM), Arduino 101 (Intel Curie) all have different tone implementations that may behave slightly differently, but most commonly a timer is used and the timer is immediately reconfigured while it's running.
Depending on the timing of the moment your code requests a new frequency, relative to the waveform's phase, you can get a variety of different results until the timer resets. Then it will begin a new cycle which will be at the desired frequency. But before that next cycle begins, the previous waveform cycle can become something much shorter (higher frequency) or longer (low frequency), depending on whether the hardware timer happened to be incrementing with a value lower or higher than the new setting.
If you only call tone() infrequently, it's not noticeable. One bad cycle (neither the old nor the new frequency) among many thousands of good ones before and after the change isn't easily perceptible to humans. But as you call tone() more rapidly, the effect becomes worse. Depending on how the timer works in the chip you're using, it's also quite possible you'll sometimes reduce the timer threshold after the timer has already incremented past it. That can result in 1 much longer stuck-high or stuck-low pulse until the timer rolls over and begins a new cycle at the new frequency. You might think of 1 long pulse as a low frequency, but it actually has broad spectral content.
This issue came up several times with Teensy. Many people attempt more complex projects on Teensy... This tone issue is very subtle and difficult to understand. Believe me, it's a hard issue that I've put a lot of effort into solving this problem well (on the newer 32 bit boards). Several months ago, I redesigned tone() on Teensy 3.x to queue changes. The current cycle is always completed, and then the new frequency begins when the waveform phase is at exactly zero degrees. Any new tone() changes during the new waveform are written to the buffer, and the last tone setting during the current waveform becomes the next waveform's period.
Perhaps this will all be a non-issue for you. Or maybe you'll even prefer the rich (but very code timing dependent) spread of other spectral content. I actually have heard from someone who wanted that behavior, even believing that sound containing lots of other frequencies was correct because it's what you get out of Arduino Uno when running a tight loop that changes the tone. But usually it's pretty easy to notice you're getting other sounds than you requested, if your code changes the tone setting rapidly enough.
Anyway, if you've taken the time to read this long-winded message, at least you'll know to look for this possible issue.