... Adjust whenever recording, regardless whether there is any overdub
playback too.
May adjust by discarding samples when the Track Shift after Record preference
is negative (as by default); or, by inserting silence into the start of the
recording, when that preference is positive, though that may be less useful.
Perhaps the preference control should no longer be called "Track Shift after
Record."
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.
... This even makes it possible to remove the prohibition of undo and redo
during transport, not that we want to though. Playback and recording will
continue, using track objects that might not be in the current project.
... Write only one variable in audacityAudioCallback, to be read (maybe in
another thread) by AudioIO::MidiTime().
The non-Alsa case behaves essentially as before: it wasn't broken, so it
isn't fixed, though it is rearranged.
... I am not sure that this will solve all problems of jittery play, but I do
think this will solve the problem of a rush of slightly late notes at start of
play.
... and hoping it is positively helpful for Linux.
In AudioIO::MidiTime(), compute one of the terms by different means.
Use PaStreamInfo::outputLatency.
Do not use the difference of PaStreamCallbackTimeInfo::outputBufferDacTime
and PaStreamCallbackTimeInfo::currentTime.
Which debugging shows is very nearly the same value for Windows and Mac.
But we suspect the PaStreamCallbackTimeInfo fields are not correctly reported
on Linux.
... At least it fixes the gross problem; but there seems to be a small
accumulation of error still each time around the loop, that I don't understand
yet.
... Used to be, it became true too soon when play started after time 0, so
AudioIO::IsStreamActive() might become false too soon -- except that now there
is always a portaudio stream when there is a midi stream, so that didn't happen.
Mistake was to add mT0 to MidiTime(), which already has mT0 for its origin.
This error would affect nothing if you just let play to the end without trying
a keystroke command. The error might have been enabling the wrong commands.
... after I reflected more on the explanation of it in the long comment at top.
Brings back the use of PaUtil_GetTime() but now calls it also in the audio IO
callback, so we can correct the unspecified origin of times supplied to the
audio IO callback to agree with the PaUtilGetTime() clock.
Thus the Midi time calculation is again based on the clock time of the other
thread that calls MidiTime, making it a few milliseconds more accurate, while
avoiding subtraction of two times based on widely different origins, which
made the big numbers that overlowed and caused Bug1714 to happen.
Don't assume Pa_GetStreamTimePaStreamCallbackTimeInfo origin is time-of-day.
portaudio.h says you should not, and in fact it was not.
The report is that this gets us some play, but there are still freezes.
Instead, always start a portaudio stream (if there is either a note track or a wave track). This ensures that playback is always in sync (eg when recording), and gets rid of a lot of duplicate logic throughout.
Scrubbing (currently) still doesn't work with only note tracks, but it should be easier to fix that now than trying to reimplement all of the scrubbing time logic.
Conflicts:
src/AudioIO.cpp
mMidiPlaySpeed doesn't handle all of the options provided by time tracks,
and in fact doesn't even use time tracks. Using the time track
instead allows note tracks to remain synchronized with the rest of the audio.
mMidiPlaySpeed _did_ work where it was used in the transcription tool
bar, but that already updates a time track so no special handling is
needed.
The fields in AudioIO are simply unneeded (commented out, declared but never implemented, or otherwise unused).
mLastMidiPosition (in NoteTrack) looks like the vestiges of a far older attempt at MIDI playback; the field itself is completely unused though so it is safe to remove it.
* MIDI Device Info menu item, like Audio Device Info
* MIDI device info in crash reports
* Only enabled with EXPERIMENTAL_MIDI_OUT, but tracks info related to the (unimplemented) EXPERIMENTAL_MIDI_IN
... 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.
... And in some places where a library uses signed types, assert that
the reported number is not negative.
What led me to this, is that there are many places where a size_t value for
an allocation is the product of a number of channels and some other number.
