Delays from start/stop are not handled correctly

[rchanrussell]

Code is missing Jack's transport and timebase interfacing/controls.

TODO: read up on these, review examples, review other audio software that uses them to understand them. These are used to handling sync issues so we have a consistent delay from recording and playing. Comparing with a drum machine shows the delays lead to a very noticeable phase cycling, within even a few loops.

[rchanrussell]

Rather than work with transport/timebase interface, I am going to manage things by taking into account buffer delays:

• 2 buffer delays for both input and output buffers.
• recording to existing tracks or overdubbing - 4 buffer delay - recording track data will arrive behind master's current index by 512 samples

Issues:

• input data will be delayed 2 buffers from monitor when you start recording, when stopping recording need to get the last two buffers otherwise the data will not match the duration the user selected
• need to use the partial buffer delays as well, but first manage the buffer delays, currently these are not used

[rchanrussell]

Latest patch includes buffer counting to help understand the delays. It would appear that recording and stop-recording do not (but could) result in a missed buffer. The issue above regarding 4 buffer delay will have to be double-checked, as I found a bug whereby the mixdown would not mixdown if currIdx was not less than endIdx which is silly given the indices are not updated at the time of the mixdown, so I noticed thanks to the callCounter that I was missing the mixdown calls until recording stopped - data was still there of course but anyway.

With callCounter and with jacks frame counts, telling you where you are in the current buffer, I should be able to remove the delay.

While testing, I was able to keep in time (yes, human action is the biggest factor) far better, as the skew took many iterations.

TEST METHOD: connect a metronome, start on the one, count to 4, end on the next 1. The more accurate you are, the better the sound is. How it sounds can be compared to what I learned with: https://www.youtube.com/watch?v=3zZRy-UArXM

Kudos to that channel as it helps!!!!

[rchanrussell]

Wrong location for callCounter -- don't place in event handler functions (called by controlStateCheck which is called by playRecord) -- place in the UART processing function, as this is when we actually receive the command and this is the mroe accurate measurement of the delay.

[rchanrussell]

After updating callCounter and turning the rec_frame_delay and play_frame_delay back on, or adding it back in, I still have to iron out the delay in a more concrete way.

I will update the external controller, which is an Arduino UNO, to not be a user-input, but instead a tester. By trying to send out, via a loop, the start and stop with a consistent delay (tolerance of arduino will be a factor), this can be compared against the indexes and the callCounter and the frame delays.

Automating will take away the huge variable, my own ability to remain in time, thus providing better empirical data regarding delays and allow finer tuning of the algorithms.

Todays patch is hopefully better than the last, if not for at least providing delay data.