... so there is only one update per track of the atomics in RingBuffer in each
pass of the loop in FillBuffers, which will be needed to synchronize RingBuffer
and TimeQueue correctly.
... Contrary to the old comments, this class was no longer thread safe with
multi-core, because of the possibility of out-of-order reads and writes.
Use the minimal necessary memory ordering, not the default and maybe expensive
std::memory_order_seq_cst
At least one clicky recording has been seen where many small groups of
samples, a common power in two in size, seem to get displaced rightward.
I suspect out of order reads and writes might have caused that and this commit
might prevent it.
1) When the program detects this, insert zeroes into the recording to keep the
other good parts synchronized.
2) When recording stops, a message box alerts the user, and a label track is
added showing the lost parts, labelled with consecutive numbers.
3) A menu item visible in alpha builds only is added to Tools, to simulate
recording errors at random times and test the reporting feature.
freeze to risk fixing it now. Will readdress after 2.0.5 is
released.
Basically, RingBuffer is ill equiped to handle an input stride
other than 1.
Thanks to Peter for testing this for me.
the job quite nicely...well, given the "stride" information he needs. And in
some cases, it will just use memcpy() so it may improve capture performance a
bit more.
