You just need to keep those deltas as constant as possible, the driver implementation is not really in your hands. Given bad enough spikes, even averaging deltas will jump around. Your timing code needs to be smart (not just clamp numbers) - you need to treat possible spiky deltas before you feed them to the buffer - need to identify a DT as a spike or not :P
You can also possibly imlpement double buffering - one that stores and averages deltas every frame, and one that adds the average value from the first buffer every time it fills up, then use the average from the second buffer as your DT.
Or you could just simply give some time at the beginning (after things are loaded and started drawing, like a 'Get Ready' screen for a few seconds) to fill up the delta buffer, and store that average value to use for the rest of the 'level' execution (would need to use real delta for other screens).
Just make sure you treat those spiky deltas with some extra logic and averaging should be sufficient enough. If you want to look into equalization and noise reduction algorithms you might achieve better results :P
You can also possibly imlpement double buffering - one that stores and averages deltas every frame, and one that adds the average value from the first buffer every time it fills up, then use the average from the second buffer as your DT.
Or you could just simply give some time at the beginning (after things are loaded and started drawing, like a 'Get Ready' screen for a few seconds) to fill up the delta buffer, and store that average value to use for the rest of the 'level' execution (would need to use real delta for other screens).
Just make sure you treat those spiky deltas with some extra logic and averaging should be sufficient enough. If you want to look into equalization and noise reduction algorithms you might achieve better results :P