stop-and-set-cursor: cursor moves too far

Just observed:

Audacity 2.0.3, windows 7.

Use the play/stop-and-set-cursor command (ctrl-A by default) repeatedly to start and stop playback.

The cursor is not at the last thing I heard, but a bit farther right. Thus Audacity does not play back everything but skips little bits.

Same observed with play-at-speed above 1x and stop-and-set-cursor. Perhaps this makes the discrepancy more obvious.

I suppose this involves output buffering. Tell me if there is a playback setting to mitigate this problem. But should it be a problem at any setting?

Rather than play the missing bits, I’d rather have the cursor corrected, so that the stop points correspond as closely as possible to my reactions.

Reducing the “Latency : Audio to buffer” setting seems to reduce the delay, but don’t reduce it too much or audio playback will not work properly.

I’m experimenting with generated click tracks at 1/4 second intervals (like counting “one-onethousand two-onethousand three”). I try to stop as near as I can at the count of “three.” (Actually at playback position 2.0 s.) The cursor is typically 13 to 15 hundredths of a second past that. Sometimes I cut out the “three” and it’s between 11 and 12 hundredths. Of course I don’t know if this may vary with other CPU load.

I’m trying to develop a Nyquist tool (discussed here in which the point where I stop playback is an important datum. I find the 1/10 second or more imprecision to be a bother. But for now I might program this correction into my tool and be happy.

Steve, I thought that setting affects recording and it is under recording preferences. It works both ways?

Maybe fixing my Nyquist for now will be the more convenient thing. Leaving the latency preference too short will cause grief for recording.

Is it not coincidental that the default preference is 100 and my measured discrepancy is around 130 ms? The extra 30 ms may be the component of the problem in PEBKAC that you guys can’t fix, so I may need the tweak in my code for best results anyhow.

It’s indeed a nuisance. You have to press the key before a word is finished in order to place the Cursor shortly after it.
The stop/set command does not take into account the playback latency.
It should at least move left by the latency correction as it is set in the preferences.
I wonder how your values would be with an ASIO Version of Audacity.

You’re unlikely to get much closer than about +/- 10 ms accuracy from tapping on a keyboard (probably worse).
If you have set up “latency correction” as described here: you will probably find that the delay before stop is about the same as the latency correction figure.

Using Audacity with Jack Audio System (Linux) the latency before stopping is just a few milliseconds - a lot more accurate than I can tap the keyboard.

Curiously, my experiment to measure the discrepancy often gives 136 ms and 159 ms but not values in between. Something else is getting discretized. If I count samples I likewise see some common values that differ by multiples of 1024 samples. So perhaps I can’t get more than 23 ms precision in where I put my stop, but that should be good enough!

Do you mean that the delay is minimized if the correction is removed (or set to positive)?
Isn’t it rather the normal Sound Card latency, that is not taken into account?
I have to test this.
Besides, pressing keys at the right time is much more precise than one might think, especially if you’re prepared for it. I am sure that I can do better than 1/10 s, but the key way produces an Initial delay. Laptops are therefore more accurate with their Little elevated Keyboards.
PS. Steve has written another post inbetween.
The 1024-sample buffer is most likely responsible for the quantisation effect.
However, the Keyboard Settings from the control panal may also have a certain influence.

I suppose these are all reasons just to put that correction knob in my program and experiment to find an acceptable value.

But meanwhile it does seem reasonable that Audacity should replay everything if you start and stop repeatedly as first described. But it’s not a show stopper for me.

As for the precision (as distinct from the accuracy), 23 ms would be good, but a few tests suggest that when I reduce program latency there is some smaller power of 2 samples. So using as little latency setting as I can may still be worth it. Supposedly the human sense of timing can be trained to 1/100 sec, right? That’s 10 ms.

Append record shows this very clearly. If you do SHIFT + R followed by SHIFT + A, SHIFT + R then starts recording from the cursor which is after the end of the track, and so this pads silence between the split line and the cursor. In this case it seems to make sense for SHIFT + R to move the cursor back to the end of the track.

We’ve had this argument before in fact that if you SHIFT + A after Pause (as you might to make an edit at the Pause point), the cursor appears after the point where the Pause was. I think again here there could be a case that the cursor should move back to the Pause point given it seems to be a defined place. This may be harder to do though, and if you could do it in this case you could probably move the cursor back to a more correct position when you use SHIFT + A after playback.


I tried going haltingly through a click track with pause instead of ctrl-a and it never seems to omit any part of the playback. It seems it might even be replicating some – playing a few samples after the stopping cursor point. Even so I’d think that is more acceptable behavior. Is there any good reason, or technical difficulty, preventing ctrl-a from behaving likewise?

I guess you mean ‘shift-a’, not ‘ctrl-a’.
The same behaviour is observable for ‘set (or extent) left [right] selection’.

Shift-a, yes, I forget because I use a non-default key preference.

On second thoughts, I’ve suggested before that it may be useful if you deliberately click after the end of the track then append record from there that silence is padded between the current end of the track and the click point. So perhaps it is better that when SHIFT + A sets the cursor after the end of a track, it then returns the cursor to the end of the track.

The trouble is that delayed human reactions and latency variability come into play. Even if I set audio to buffer to as low as 25ms (or as low as 10 ms with JACK on Windows), ] still sometimes lands almost as far after the audio I wanted to mark as it usually does when buffering is 100ms.

So although the buffer and the latency are not taken into account when using SHIFT + A, it seems hard to compensate for this, unless Audacity has some record of the Timeline position at which the command was sent and can set the cursor back to that point.

It seems the track end after stopping recording and a Pause position is quite akin to such a Timeline position (more accurate).


I don’t understand what Gale is getting at. Go through a recording start and stop fashion with pause, and you hear everything. Use stop-and-set-cursor instead, and you don’t. Why is that inconsistency a “feature?”

Perhaps I don’t understand what your issue is fully. I understand the SHIFT + A causes the cursor to “move too far” (your own description). I think this means the cursor does not stop quickly enough when using SHIFT + A compared to when using SPACE. Right or wrong?

Pause has exactly the issue as you describe it (SHIFT + A used after Pause sets the cursor after the Pause position, so the cursor has moved too far).

If the cursor travels too far, then when you play the selection after ], I would have expected you hear more than you intended, not less. I would have expected when you play after SHIFT + A, you hear less than you intended. Isn’t that what you mean?

If that’s what you mean, how would you propose fixing it except by moving the cursor back from where SHIFT + A actually sets it down, and how do you propose to ensure that movement accounts for variable latency and variability in your own reaction time? What I am getting at is that when you append record then SHIFT + A, or Pause then SHIFT + A, Audacity has some known point on the Timeline to move the cursor back to.


Let me try again.

This problem has nothing to do with my variable human reflexes. This has nothing to do with comparing shift-a with space. The problem is that what the cursor advances over is not exactly what was played back.

Start playing something like a click track at 240 beats per minute. Then just hit pause repeatedly, no shift-a. You hear all the clicks. You miss none.

Go back to start, hit play, and now hit shift-a repeatedly, which should likewise start and stop the replay but march through the whole track. You do miss clicks. Each time you hit shift-a, the place where the cursor stops does not correspond to the last thing you hear. It is instead too far right. With default latency setting, about 100 ms (or perhaps it’s always exactly that?) is skipped.

If the program can put the green playback position after pause in the right place, why should correct cursor placement be different?

I hadn’t tried pause and shift-a before, but I see what you mean now. Don’t you think that alone is undesirable behavior?

@Paul, I see what you are getting at, but I still experience the symptoms I was describing of playback restarted after SHIFT + A. These must be caused by the cursor going too far.

I am not sure the symptoms you are describing (before you restart playback) are caused by the cursor going too far. Perhaps this is where the confusion is.

I think it is exactly to do with it, because if you press SPACE when directly over a click, you always hear that click, just as you do when your press P. But if you press SHIFT + A when directly over a click, you may not hear that click. I quite often do hear it, even at default 100 ms Audio to Buffer, which is why I was finding it hard to follow you.

Playback cannot be different until you press one of those choices above, because Audacity cannot predict which you are going to press.

“Missing clicks” (at the point you SHIFT + A) seems to be another symptom (call it symptom A).

The symptom I was describing (call it symptom B) is also true, that when you restart playback after SHIFT + A, you cannot hear the audio immediately following the point where you pressed SHIFT + A (because the cursor moved too far).

Is the cursor moving too far causing symptom A as your report title suggested? I’m not sure it is. Perhaps the buffered audio is being cut off at the exact point when you press SHIFT + A, instead of being allowed to complete (as it seems to be when using SPACE or P). If so, moving the cursor back won’t help symptom A.

I described what I found. At 100 ms the playback is often skipped but by no means always. At 25 ms the playback is usually included but not always.

Also the exact place the cursor ends up after SHIFT + A is variable. A shorter “Audio to buffer” setting usually makes the cursor move less far to right, but not always.

That is what I asked above. I am not defending that. I am saying the following.

  • When you SHIFT + A during playback there is no physically obvious place to move the cursor back to.
  • Given the latency variability I see (and despite what you say, variable reaction times) it may not be possible to always move the cursor back to the “correct” place.
  • There is a physically obvious place for SHIFT + A to move back to if you were append recording before SHIFT + A, or if you paused before SHIFT + A.