#1682 MIDI audio recording delay from wave file start

[musewhirl]

This is a question concerning consistency between RG versions. Below is scenario between v18.12 on Debian buster and a compiled v23.12 on bookworm. It can be done with any version of RG though, and if you have virtual images, it should be easy to set up.

Steps to reproduce:
Connect RG to any external synthesizer ready to receive MIDI and send back audio for recording
Set the MIDI track to any instrument which produces a short burst of audio e.g. a simple click or short audio spike
Place notes starting right from measure one, beat one i.e the earliest possible targeted for the start of the wave file, and then a few more at one per beat to fill a few measures (I tested at around 60 BPM, but that shouldn't matter)
Connect MIDI audio output to any RG input which is wired to an audio track and hit record

That's it for obtaining a usable wave file. Import into any audio application and note the time from the start of the wave file itself to the first audio wave spike. This post is about that time delay. Obviously, there is and will always be latency. But I noticed that in some old files from v18.12, this delay when ALL known factors were kept the same, was similar enough not to mention. Factors include the same version of RG on the same OS etc, as well as the same audio interface and synthesizer. There were no intentional audio upgrades either, although various kernel upgrades did occur in buster. But still the delay was not noticeably changed.

To test this in v23.12 on bookworm, I had to compile it locally due to a previously mentioned bug in RG v22.12, which has now been fixed perfectly. Presumably lots of audio software changed along the way. Although I have limited testing time for this version, it seems like among themselves, the wave file delay is similar, but compared to the previous scenario, the delay has grown considerably. In fact, visually I see a consistent factor of 2-3 times larger on average than before. I thought I would post now since meaningful results between versions can only be obtained in a controlled environment.

RG can do nothing about how long it takes for audio to travel down the OS audio stack, off to who knows what synthesizer via whatever audio interface happen to be around and all the way back. However, developers presumably have control over their environment, so at least only the RG version changes. Then we can determine whether the delay is within the start to record leg of RG or after RG input to wave file creation.

If in RG, does RG simply have more to do now and that caused it?
Is there a bug of some kind causing the extra time delay which was introduced between those two versions?
Is it something varying between versions i.e. getting longer all the time or even random delays?
Perhaps it's just something in my environment caused by the upgrade or having to compile it myself?
Finally, it may just be "latency that folk's have to get along with"

It is not certain whether humans can hear the delay between old RG audio tracks imported from v18.12 into v23.12 to play along side new ones based just on the wave file start alone. Although the measuring tools were inadequate, I thought I saw a difference of some 80 ms between versions. Not from the start of the wave file, but between the first audio on the timeline? I'd have to retest to make sure I didn't miss something.

But in music timing is everything, so it would be nice to know what to expect under normal conditions (or at least your case), so in future anything unexpected can be reported.