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

[Paul L]

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.

[steve]

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.

[Paul L]

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 http://forum.audacityteam.org/viewtopic ... 39&t=71739) 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.

[Paul L]

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.

[Robert J. H.]

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.

[steve]

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: http://manual.audacityteam.org/o/man/latency_test.html you will probably find that the delay before stop is about the same as the latency correction figure.

[steve]

I wonder how your values would be with an ASIO Version of Audacity.

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.

[Paul L]

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!

[Robert J. H.]

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: http://manual.audacityteam.org/o/man/latency_test.html you will probably find that the delay before stop is about the same as the latency correction figure.

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.

[Paul L]

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.