60beat GamePad

The audio carrier rate is 44,100 Hz.

Ring buffer size for processing is 2^11/44100 seconds, or about 46.4 ms.

In testing, the data comes in 3 pulses: the first pulse is empty, the second has data, and the third is truncated due to likely powerloss.

The Int16 stream must first be smoothed and cleaned. This is the method the original 60beats logic used to process the waveform but might be better served with a more modern and powerful reconstruction filter.

The Int16 value is then stored in a ring-buffer of 40 bytes size which is used to make room for repairing damaged waveforms. The Int16 16 samples ahead is read, which is from the prior loop of the ring buffer and is initially 0 and checked for peak/valley truncation.

The maximum absolute amplitude is stored in another 40 entry ring-buffer. This buffer is checked to find the maximum amplitude in the sample window.

Gather the min and max amplitude for the next 9 frames (after frame 18 rather than) and use it to find the true middle point of the waveform.

If the amplitude has gotten somewhat quiet, start to process the frames in the ring buffer. Attempt to process the half-save width counts stored so far. Note we haven't reached the code that stores these yet so this buffer will be empty initially. This test attempts to use multiple different dividing lines between the length for a long and a short half-wave looking for one that generates a valid bitstream.

After handling good but older data, we're still in the middle of processing new data. Count the time between crosses of the adjusted 0 line (accounting for any waves that are way too short suggesting signal damage).

Below is the bitstream check that attempts to find a valid bitstream from the length of the data.

Further documentation pending attempting an alternate reconstruction filter.