1
0
mirror of https://github.com/cookiengineer/audacity synced 2025-11-23 17:30:17 +01:00

Try to clarify real time / track time distinction in comments...

... 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.
This commit is contained in:
Paul Licameli
2018-08-11 15:03:29 -04:00
parent 72b71bbe08
commit ce1ce688ff
2 changed files with 10 additions and 9 deletions

View File

@@ -1988,7 +1988,7 @@ int AudioIO::StartStream(const TransportTracks &tracks,
// killing performance.
//
// (warped) playback time to produce with each filling of the buffers
// real playback time to produce with each filling of the buffers
// by the Audio thread (except at the end of playback):
// usually, make fillings fewer and longer for less CPU usage.
// But for useful scrubbing, we can't run too far ahead without checking
@@ -2101,7 +2101,7 @@ int AudioIO::StartStream(const TransportTracks &tracks,
{
mPlaybackBuffers[i] = std::make_unique<RingBuffer>(floatSample, playbackBufferSize);
// MB: use normal time for the end time, not warped time!
// use track time for the end time, not real time!
WaveTrackConstArray mixTracks;
mixTracks.push_back(mPlaybackTracks[i]);
@@ -3874,7 +3874,8 @@ void AudioIO::FillBuffers()
bool progress = true;
#ifdef EXPERIMENTAL_SCRUBBING_SUPPORT
if (mPlaybackSchedule.Interactive())
// scrubbing does not use warped time and length
// scrubbing and play-at-speed are not limited by the real time
// and length accumulators
frames = limitSampleBufferSize(frames, mScrubDuration);
else
#endif
@@ -4430,7 +4431,7 @@ void AudioIO::FillMidiBuffers()
break;
}
SetHasSolo(hasSolo);
// If we compute until mNextEventTime > current audio track time,
// If we compute until mNextEventTime > current audio time,
// we would have a built-in compute-ahead of mAudioOutLatency, and
// it's probably good to compute MIDI when we compute audio (so when
// we stop, both stop about the same time).