... 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.
... 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.
... 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.
Rather than 'cut' (i.e. drop, not cut as in 'cut preview') channels immediately, we now only do so
if their last gain was already 0.0. Instead they micro-fade out. Later when the channels come back,
their last gain will be 0.0, so they will micro-fade in.
A comment explains that the code would be cleaner if we just computed gains, and not whether to
drop channels.
... We need to start the polling of mouse state before starting the audio
stream, and not "nudge" AudioThread, so that AudioThread primes the ring
buffer correctly, not inserting some silence.
This requires yields to timer events in AudioIO::StartStream.
On launch, Audacity scanning the sound system causes Pulse to grab
exclusive control of the audio device, causing the device to be
unavailable until Pulse times out and releases it.
If an attempt is made to start recording from the hardware device (hw:)
immediately after launch, PortAudio will time out before the device is
released. In this case we need to retry opening the capture stream.
(This also applies to monitoring).
... Rather than the confusing old terminology of "warped" time, meaning the
real time after accounting for time track, though that persists mostly in the
names of variables now mostly used only within PlaybackSchedule.
"Track" time refers to a position in a wave track, as indexed by the time
ruler.
"Real" time is indexed by the other scale of numbers drawn in the time track,
which is drawn on the screen with nonuniform spacing (so "warped" in that
sense), but it corresponds to uniform actual time.
