Cursor position in relation to the waveform heard

Audacity 3 Help Forum Windows
1

In both the previous and the recent 2.2.0 versions I notice that the cursor position is always about 20ms in advance of the specific point of the waveform heard.

To reproduce this, open an audio file containing clear peaks from e.g. a bass drum, and make a selection containing just one such peak. You will notice that after pressing “play”, at the moment the peak is heard, the cursor is already at a position about +20ms on the right of the peak.

Since it is obvious that one cannot do proper audio editing under these conditions, my guess is that this problem must have been addressed years ago and that I experience it due to my particular configuration. Also, I realize that this is a hell of a problem to troubleshoot, relating to both audio and video hardware and drivers, plus the inevitable latency of the soundcard itself and the OS.

So I am guessing that there must be a hidden setting in Audacity controlling the offset of the cursor position related to the actual audio output so one can compensate e.g. for latencies of the hardware.

I should clarify that when using non-free audio editors (on Win7 x64) I don’t experience this problem, i.e. the peaks of the waveform under the cursor and the sound heard do coincide perfectly.

I would be indebted if somebody could reproduce the problem or suggest where precisely to look in Audacity’s visible or hidden settings.

2

What you are describing is an inevitable consequence of buffering by an “on demand” sound system.
My usual operating system (which I’m using now) is Linux, and I can easily reproduce the problem when using the default ASIO / PulseAudio sound system. What’s happening is:

  1. You press the Play button (or an equivalent shortcut)
  2. Audacity starts playback - the playback cursor starts to move and at the same time begins sending audio data to the computer’s sound system.
  3. The computer sound system opens a new playback stream
  4. Audio data floods into the sound system playback buffers
  5. When the playback buffer is sufficiently full, audio playback begins.

Yes, that is a problem, but in most cases it is not a serious problem. This issue is the reason why high performance, low latency audio drivers have been developed. On Windows, most non-free audio recording software use ASIO drivers by default (Linux uses “Jack Audio System” for the same purpose). When using ASIO (of Jack), the process is a bit different:

  1. The computer sound system is running continuously
  2. You press “Play”
  3. Audacity starts playback
  4. Audio data floods into a very small buffer and begins playing almost immediately.

Even with high performance, low latency drivers, there is still some delay, but it is hardly noticeable, and all data that is sent by Audacity will play from start to end because the playback stream is running continuously.

Because there is always a delay (latency) when playing or recording audio, multi-track audio software performs a “trick” when doing overdub recording, which is to compensate for the round trip delay when recording a second or subsequent track.

Quick description of latency compensation:

Say you have an audio track, you play it through your speakers and record that sound to a new track via a microphone. Not surprisingly it takes time for audio data to be read from the hard driver, work its way through the playback buffers, get converted to analog, play through the speakers, get picked up by the microphone, convert back to digital, work its way through the input buffer and finally be written to disk. This results in the second track being offset from the first track, so the waveform in the second track is later than the waveform in the first track.

The “trick” is to find out exactly how long the “round trip latency” takes, and then to shift the second track to the left so as to compensate for the latency. When set up correctly, this “latency correction” will pull the second track back so that it aligns correctly with the first track.

How to set up latency correction is described here: http://manual.audacityteam.org/man/latency_test.html

Unfortunately, ASIO is provided by Steinberg under a restrictive license (the source code may not be distributed), which is incompatible with Audacity’s open source (GPL v2) license (which requires that the source code is available). This means that Audacity cannot ship with ASIO support without being in breach of one or other license.

Fortunately, modern version of Windows now has its own high performance, low latency drivers, called WASAPI. Most modern sound cards ‘should’ work with WASAPI (sadly, some don’t, but I think that most do these days).

I’d suggest that you try setting the “host” to WASAPI in the device toolbar and see if your sound card performs better like this. The next step is to set up latency correction as described in the previous link.

3

Thank you very much for the detailed response (although I am very familiar with most of the topics you address, I’ve been doing remastering using Wavelab and ASIO since forever).

I am always using WASAPI mode. The manual page for the Audacity latency test is focused mainly on the input-output latency and allows entering a value for “Track shift after record”. It seems I’ll have to experiment with this setting and see if it has an effect on plain file playback too. Will post results.