New version of Bounce with HPET Driver - and many bug fixes - updated 22nd June 2013

Here is the new version with Jan Wassenberg's driver. This gives access to the HPET timer, a hardware clock on modern CPUs with a sepcification that guarantees accurate time with only a small amount of frequency drift and sub millisecond timing.. 

To download visit the Download page. Direct link:  Setup_Bounce_Metronome_w.exe

Then just download and run the installer "on top of" your existing version of Bounce. 

The installer is set to update newer files only for most of the files ( program itself set to update if changed). This means that all your existing settings are kept as they are during the update. Also means you can roll back to a previous version by running the previous version's installer. 

For details of changes and previous versions, see: Change Log. 22nd June update: bug fix

To access this new feature, choose the HPET timer from the droplist in Midi Timing Tweaks for Accuracy (Ctrl + 261), then run the installer to install the driver. It will be available as a new timer next time you start up Bounce.
 

My attempts to test the new timer

Sadly my laptop has stopped doing major timing glitches. This may be due to the summer weather as chip behaviour can depend on humidity and temperature, If so I may be unable to test it properly until next autumn or winter..

However, I have verified that the driver does access  the HPET timer, as best I can tell with my tests, and is working well with no issues at all. 

Note that Jan Wassenberg's driver is a "read only" driver.  What it does is to memory map  the HPET time into user space to make it accessible for user mode programs to read it.  

Other features of this upload:

A new window "Compare all timers" which compares measured  times from all the main Windows software routines for measuring time, and the HPET time. See Change Log.

Many bug fixes, most minor. See Bug Fixes

This timer currently works with Bounce Metronome only

Other programs will need to write special code to access the timer.

I am in process of writing a Code Project article to explain how the driver is used for other programmers. If anyone wants help before that article is completed please contact me and I will explain how it is done.

It can't fix timing glitches in other programs unless they are re-written to access it

The driver can't make any difference to timing issues for programs that are unaware of the existence of the driver.

I mention this since there are many online discussions of timing glitches and issues in synthesizers or sequencers. I have no idea whether these are the same issue or some other unrelated issue.

If these glitches are due to Windows timer glitches, then installing Jan's driver can't,  by itself, fix the issue. The programmers who wrote the synthesizer or DAW or sequencer would also need to update their code to access the driver.

Attempts to investigate the HPET timer for sub millisecond glitches

My laptop is still doing timing glitches of up to a millisecond, when you compare the other timers with the HPET timer. I attempted to use thes to test the new HPET timer.

However, when I recorded too audio, I ran into the issue that there seem to be other sources of millisecond or sub millisecond glitches on the GS Wavetable synth and other synthesizers on my computer. So far I have been unable to track down the sources of these glitches. So I have no conclusive data on this yet.

Writers of synths who use DirectSound have access to soundcard clocks, so it is possible that they use those and that they are in some way responsible for sub millisecond latency jitter..

Attempts to find the source of this sub millisecond "latency jitter" internally in Bounce

I tried to find out what is happening by doing the whole process internally via Bounce Metronome's own "wave shape player synth", but the results were inconclusive.

The issue there is, either I use the total sample time output so far in which case it's not a test of timing sync at all and can't introduce any jitter beyond the tiny , orten no more than  5 or 10 microsecond  timing glitches reported by the HPET timer itself - or else I use the time the buffers are received for filling. I tried using offsets from the time the buffers are received but ran into the issue that he buffers are probably sent to the app at irregular time intervals at the millisecond level. 

I haven't tried using the direct sound clocks in this internal testing, because in Bounce's wave synth player, I access direct sound through Port Audio rather than work with it directly.

If anyone reading this has insights on all this, do contact me about it. I will also mention this in the Code Project article for comment there as well.