... except Audacity.h; and in no others.
Do so even if Experimental.h gets multiply included, as in both the .h and
.cpp files.
This makes it easier to do a text scan to be sure there are no unintended quiet
changes of meaning because of omission of Experimental.h when the flag is
an enabled one.
Also move inclusions of Experimental.h earlier.
Also don't require Experimental.h to be preceded by Audacity.h to define
EXPERIMENTAL_MIDI_OUT correctly.
The bug:
1. Set Audio host to WASAPI
2. choose recording and playback devices which have different default sample rates in shared mode.
3. Set overdub, and playthrough to off.
4. make a short recording.
5. playback. Fails with error dialog.
Cause of bug:
In AudioIO::GetBestRate, the last returned sample rate is cached. If the function is called again, with the same requested sample rate, then the cached value is returned. So in the above steps, when GetBestRate is called for playback, the sample rate of the recording device is returned.
Fix:
Include in the conditions for returning the cached rate that the values of playing and capturing as the same as in the previous call.
... which will make it easier to change the types of those containers to
std::vectors of other string-like classes
for wxString,
IsEmpty => empty
Clear => clear
Alloc => reserve
for wxArrayString,
Count => size
GetCount => size
IsEmpty => empty
Add => push_back
Clear => clear
Empty => clear
Sort => std::sort (only with default comparator)
SetCount => resize
Last => back
Item => operator []
Alloc => reserve
Problem: up to about 300ms was intermittently truncated from the end of recording.
The bug was introduced by commit a0256e9.
The fix: in this commit, the line:
the line:
mRecordingSchedule = {}; // free arrays
was added to the lambda in the definition of cleanup at the start of AudioIO::StopStream()
If this line is changed to:
mRecordingSchedule.mCrossfadeData.clear(); // free arrays
then this has been found to fix the bug, and the vector is still cleared.
Clearly, the reinitialization of one or more of the other data members of mRecordingSchedule was causing the bug.
Which of the these reinitializations are the problem, and why is not known, and due to the nature of the problem could well take some time to find out.
Flipped some conditions and used if else-if to reduce the indentation in code.
This makes the code more readable. No change in functionality.
Also created UpdateTimePositions() and made some bool functions void.
new variable mMaxFramesOutput used to communicate positional change.
AudioIO.cpp has nearly 6000 lines and needs to be broken up into separate aspects.
The main point of the new split is to better separate the time critical callback code (that runs in the portaudio thread) from the code that interacts with the disk (that runs in the Audio Thread).
We ask 17 times for different rates, and for some drivers that is too much of a flood.
Workaround is to use a small delay between requests.
Only happens at start up, so is acceptable to just always do it.
This is not a proper fix, as we do not fully understand the problem - which is in release builds only.
It may be enough though to get us through to release.
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.
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.
