Quote:
Originally Posted by Guod3
Feel free to post some code fragments.
What I've implemented so far has the granularity of block_size/SR. This is the time between calls to ProcessReplacing. For a buffer of 128 this is around 2 to 3 ms @48kHz. If a midi clock happens every 20.8ms (i.e.120BPM) there will be some jitter in the clock but it doesn't seem to matter. However if the buffer size is set to 1024 or some other large number and the clock receiver is an outboard delay, then you hear glitches.
Does the sleep function go down to millisecond resolution? Does this determine the accuracy (jitter)?
|
Don't have the code right here but:
The precision matter at high BPMs. Also - as you say you can't really trust the ProcessReplacing() because it's variable. You could use it as first priority whenever possible, and then switch over to a timer thread if the interval is too low.
1) thread::sleep for the full time - 2 ms.
http://en.cppreference.com/w/cpp/thread/sleep_for
Then use the std::chrono::high_resolution_clock to measure the time actually slept and subtract the full sleep time by this elapsed time. What you then get is the remainder to sleep.
But when it closes down to 1-2 ms you should just do an "busy wait", which is basically a for loop checking the remaining elapsed time to be slept and break when it has reached it. That way you get the most stable clock possible. It will use some CPU but at least it's better than for example Reason's MIDI clock.
I anyone knows a better way to make a MIDI clock let me know. I have tried everything from multimedia timers etc to have stable timing on sub ms precision, but it's impossible unless you have a dedicated CPU core for realtime processing.