... but we don't need to make it as precise, using steady_clock.
Do this so that the Audio thread doesn't read the same polling message twice,
halting the scrub. It's all right that it might miss one of the messages
instead.
... Instead there is just a message buffer where the polling thread leaves last
observed state, not requiring each state to be processed before it is
overwritten. The thread doing FillBuffers is now responsible instead for the
complete interpretation of the message whenever it is reinvoked, which happens
at very regular time intervals.
In fact the separate polling thread might be eliminated, having FillBuffers
invoking the polling of the mouse directly in its own wake-ups -- unless the
platform really allows ::wxMouseState to be called safely only from the UI
thread, as appears to be the case in Linux.
Note that this complicated rewrite is accomplished incrementally in the commits
of this merge branch, not all of which leave scrubbing in a working state.
... which were meant to fix growth in lag between mouse movement and play head
movement.
Recent rewrites to keep RingBuffer more populated during scrub and seek should
make this unnecessary.
... One still called ScrubQueue, which should become a simple non-queuing
buffer later, communicating scrubbing instructions from the UI or poller
thread to the Audio thread.
The other, downstream of that, supplements the playback RingBuffers with
a correspondence between samples and track times, for use by the PortAudio
thread in updating the last-played position, which is in turn used by the
UI thread to update the display.
In future this queue of times may be used as the sole, general means for
PortAudio thread to update head position, not just a special case for scrubbing.
... from the Audio thread to the PortAudio thread; the old
ScrubQueue::Consumer() function keeps only a vestigial purpose to prevent the
scrub queue from blocking.
... 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.
... this may be more than the batch size used in ongoing playback.
It is expected that this larger batch size is used only once when priming
the queue before starting play. But then FillBuffers() may attempt to
refill up to the minimum in case demand is outpacing supply.
Thus the new number defines a "yellow zone" for the queue.
