Logic changed to delay pause by one frame, if there is a need to fade out.
So we calculate whether we are already faded out, and if we are pause, otherwise delay the real pause for one frame.
Now we show "11:07:29 +" for a time 100 years, 11 hours, 7 mins and 29 seconds in the future, rather than ASSERTing.
The + should probably be mentioned in the manual. "In the countdown, times more than 24 hours ahead aren't shown fully. A '+' sign after the time indicates that it is more than a day ahead."
Problem: When using WASAPI on Windows, the last "latency buffer length" of a selection is not played. This is a fairly nasty bug for those relying on playback when making fine adjustments to the position of the cursor, or the start or end of selection.
During playback the "latency buffer length" has no effect on the actual latency of the playback, but the playback cursor is positioned as if the "latency buffer length" did have an effect, that is, it is positioned by this amount after the audio being played.
So an obvious workaround is for the user to set the latency buffer length to zero when using WASAPI. However they then have to remember to change it if they use another audio host.
Fix: The real problem is presumably a portaudio bug, but this fix just hard codes the workaround given above. For playback, when using WASAPI, set the suggested latency to 0, regardless of user setting.
... 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.
