... See allocation of RingBuffers in AudioIO.
Playback buffers always used floatSample format so this change has no
effect on them.
But we also want no extra dithering applied during recording, where the capture
format might be narrower than float.
... 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.
... whenever they really describe the size of a buffer that fits in memory, or
of a block file (which is never now more than a megabyte and so could be fit in
memory all at once), or a part thereof.
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.
Paul Licameli
James Crook
Paul Licameli
benjamin.drung@gmail.com
lllucius
martynshaw99
ra