[RealityVoid]

Do say more! What was the problem with the clock, more exactly? I believe you, I've had issues caused by clock skew and CAN bus for example, when you have a small error that is amplified on beach bit enough time, errors add up and you eventually get out of synch.

But in the case if sound, I would have expected the skew to be less of a problem. Also surprised how the orof instantly know. It took me a while to figure out. How did you fix it? Cool story!

[analog31]

One simplistic way is to successively add a small constant to a large integer, and generate the waveform from the most significant bits. A "cent," which is 1/100 of a semitone, is a factor of about 580 parts per million, so you can work out the precision needed for the constant. On a microcontroller, you can control the timing with a PWM, which runs independently of the processor and its timing foibles.

Proof is left as an exercise to the student. ;-)

[RealityVoid]

> On a microcontroller, you can control the timing with a PWM, which runs independently of the processor and its timing foibles.

That is not really true. You usually have a couple of clock sources on a MCU, but the clock gets propagated down the clock tree and the source, and most of the times, the PWM has the same source clock as the CPU. Indeed, I think if you're before the PLL the clock is more accurate as in you get less jitter but the overall drift is the same. You might have distinct clock sources but you need a specific hw and a specific configuration.

[analog31]

Is it enough to have an audible effect? We’re not talking cesium clock levels of stability here. Now my curiosity is piqued, I have to figure out a way to measure this.