We keep track of the current sample position during playback, to correctly align a graph and corrections made by the user with the audio. For this, we need to detect if there is a jump or loop-back, so that we cease working with the data we were using and fetch the data for the new location instead.
To accomplish this, inside process(), we record prevSamplePos = data.processContext->projectTimeSamples, and prevNumSampes = data.numSamples. On the next process() call, we expect that the new data.processContext->projectTimeSamples value will equal prevSamplePos + prevNumSamples, since the position plus the number of samples should get you to the first sample of the next block.
Unfortunately, sometimes Cubase (haven’t tested this in Nuendo) is off by 1, so our software thinks there has been a jump or loop, and it stops its current work and prepares for processing from the new location. For one test audio file that i use, this happens about 50% of the time, but always at the same location (or approximately the same location, I haven’t verified if it’s the exactly the same).
I’m not sure how to handle this safely. I am either recording data from the process() function, or using data previously recorded (and possibly modified) to write back to a known position. And the position has to match. Adding an extra sample or skipping a sample just isn’t acceptable. I can’t just ignore it, especially when recording the data.
Why does this happen? Is there any chance this difference will ever be MORE than 1 sample? If it’s only ever 1 single sample, then I can perhaps work around it by adjusting my copying of my internal process buffer to accommodate, and something similar when playing back later, and assuming that the current sample position is always accurate.
Or, could this be a bug in Cubase, where some kind of floating point error builds up over time until it adds a whole sample position? (If so, then I don’t get why it would happen sometimes, but not always, and why always in the same place in that one file?)