I am getting this issue on Windows 10 x64 with Audacity 2.3.3. This is contrary to https://bugzilla.audacityteam.org/show_bug.cgi?id=2094 which claims this is a Mac/Linux bug.
Procedure
- Set the “play start point” somewhere in the middle of the audio file. (Not sure if necessary.)
- Scroll so the “play start point” is just barely off-screen, to the left or right of the viewport.
- Press Space to play, again to stop. Rinse and repeat.
Audacity’s behavior
I think Audacity’s behavior can be modeled as an event-drive state machine. Each of the following tasks will trigger a series of events.
Start playback with the “play start point” off-screen to the right
- [Start playback]
- The “current playback” cursor starts from the “play start point” and moves to the right.
- Some “initiate playback” UI lag occurs, then the UI becomes idle.
- The viewport does not move yet.
- [UI idle, “current playback” cursor off-screen to the right]
- Audacity scrolls the viewport rightwards so the “current playback” cursor is on the left of the screen, which takes time to redraw.
The behavior is fairly deterministic. The “play start” point is just barely off-screen (on the left), by a distance equal to the duration of (“initiate playback” UI lag).
Start playback with the “play start point” off-screen to the left
- [Start playback]
- Sometimes: [UI idle, “current playback” cursor off-screen to the left] (second event)
- Audacity scrolls the viewport leftwards so the cursor is on the right of the screen, which takes time to redraw.
- Afterwards, the play point has already moved off the screen (to the right). Trigger event [UI idle, “current playback” cursor off-screen to the right].
Why does the second event only happen sometimes? The “current playback” cursor starts from the “play start point” off-screen to the left, and moves to the right. If the “current playback” cursor goes on-screen before the UI lag ends, Audacity will not jitter. If the UI lag ends while the “current playback” cursor is still off-screen to the left], the second event will occur, and Audacity will scroll and redraw twice in succession.
If you (start playback with the “play start point” off-screen to the right), the viewport will move just past the cursor. If you then stop and play, there’s around a 50% chance the second event will happen. If you move the viewport to the right so the “play start point” is far off-screen to the left, the second event is more likely to happen.
Once the second event happens, the “play start” point will be off-screen to the left by the same amount of time as the first redraw took (around 0.4 seconds in spectrogram mode, around 0.1 seconds in waveform mode). Since screen redrawing delay is longer than start-playback lag, every time you stop and play again, then the second event is pretty much guaranteed to recur.
Conclusions
I feel these behaviors are poorly thought out. I suggest changing how Audacity responds to certain events:
- [Start playback]
- If you start playback with the “play start point” off-screen to the left or right, the “play start position” should scroll to the left of the viewport.
- [UI idle, “current playback” cursor off-screen to the left]
- Unnecessary to change, but this could scroll the viewport leftwards so the cursor is on the left of the screen. But if users can scrub through the document towards the left (reverse playback), this is bad because it creates constant redraws.
As a result, initiating playback is no longer dependent on the whims of the “current playback” cursor, UI playback lag, and redraw lag.