Varying latency during track

Windows XP (up to date as and when they dropped it). Audacity 2.0.0. (being updated to 2.0.5. very soon).

Hi guys. I’m fairly new to this but normally computer competent, working in software as I do. There have been other threads touching on my problem but they don’t really mirror it.

I understand the principle of latency and how to correct it in Preferences. However I find that I can set the correction well for the start of a number then find it has drifted progressively at stages throughout the recording. I mean in even a single mono track + click track situation. No, I’m a reasonable musician, I can keep time and I am running a click track. I don’t mean by a couple of msec, I mean far enough out to hear obviously. In at the start then drifting behind as the track progresses. This does seem to me it could be either a hardware or a resource issue rather than a software one.

The machine is i5 750 @ 2.67GHz with 2.99GB of ram. There is 1GB of ram free and both HDDs are nowhere near full. I’m not running any other software which is exotic or resource hungry. I’m recording with a SE2200 mic through a Lexicon Lambda unit to USB and monitoring it from there. Everything seems ok when I record. Playthrough is off but there will be other settings which I may not know about or remember. Is there something simple in the setup which I have probably missed?

Try generating a 2 minute Click Track ( with a tempo of 60 bpm (one click per second).
Play it back and time it. Does it last for 2 minutes? (you may want to add an extra tone at the end)
Repeat a couple of times to ensure that you get consistent results.

Rewind to the start and then press record, with your microphone close enough to your speakers / headphones to pick up the click clearly.
Unless you have set up “latency correction” bang on (, the recorded clicks will probably be slightly off the original click track, but they should be off by the same amount all the way along.
While doing this, time it. Was it still 2 minutes?
Repeat a couple of times to ensure that you are getting consistent results.

If either of the above tests fail, try changing the “Host” setting in the device toolbar from MME (default) to Direct Sound. (If you are already using Direct Sound, try MME.

Any better?

Another thing to try: Try setting the “Audio to buffer” a little higher in “Edit > Preferences > Recording”. The default is 100 ms.
If that does not help or makes it worse, try a little lower.

Also, sample rates must be matched everywhere when you use external sound devices - in the Audacity project rate bottom left, in the rate of the tracks themselves, and in any settings in the device’s control panel or in the device itself.

Use the external device for both playback and recording in Device Toolbar .

Ensure you have the latest Lexicon drivers from . It is always worth uninstalling then reinstalling the same drivers if nothing else fixes the problem. Note those drivers do not support 64-bit XP.


Ok. I’m now on Audacity ver 2.0.5. Thanks for the advice, it makes sense and I have moved forward after taking it in, so here are a couple of answers to some of the points.

Steve: I did the timed click track test over 2 mins and it was accurate to within a fraction of a second every time. I’m not sure how good it should be. When recording the click track to a second track the latency was 256ms and was also consistent all the way through. I’ve always stuck to using Direct Sound, when I change to MME things seem to go all over the place. I haven’t played with the buffer sizes yet, I’ll give that a go next if necessary.

Gale: From what I understand the Lambda supports 44.1kHz and 48kHz and gets its selection from the software. Audacity reports 48kHz in the left corner so we should have a match there. Unfortunately most of the practical advice regarding Lambda settings during use is wrapped around Cubase which the manual assumes you will be using. I do have the most up to date version of the Lambda drivers for Win XP 32bit and I am already using external device.

I have done some more recording today and, though I am sure the problem is still there, it does not seem to be as acute. I wonder if some of it is me just getting used to working from a click track again after a break. I never have a problem with drummers but maybe a click track is just more demanding and I need more practice. I’ll be using it more this week and I’ll see how I get on. If it proves to be my incompetence as a musician than that’s fine. If not I’ll try to get a clearer picture and tie up some of the loose ends in settings and report back.

Do you guys turn off other stuff on your PCs while working with Audacity? I would not have thought it necessary but disconnecting from the local network and stopping Firewall and Antivirus may have some effect anld ease the load on resources. But I have also watched the Performance Monitor and while recording, apart from the occasional 1 or 2% blip in CPU usage, Audacity doesn’t seem to stretch system resources at all. It’s actually very impressive to see. Does this change much with increasing number of tracks to wrok with? I also have selected my system Solid State Drive for Audacity’s temp folder rather than a slower mechanical drive. Is this necessary as I don’t want to fill up the SSD with garbage?

Thanks for all the help up to now.

As few programs and services running as possible and having the same set of those every time you record will both be beneficial.

Increasing number of tracks in the same project window will slow Audacity down.

Unless the timing issues are due to dropouts in the recording I think you might be better setting the mechanical drive as the Audacity temporary directory rather than the SSD.


It should be more accurate than you can measure with a watch :wink:
“a fraction of a second” is probably the most accurate that you can expect to measure it, so that sounds about right.

That’s good.
At some point you will want to set up “latency correction” so that Audacity automatically pulls new tracks back into sync with the first track. (

In that case it’s probably best to stick with Direct Sound. (Direct Sound generally worked better for me too when I was on XP).

I’m much more of a “live” player than a studio player. I dislike working with click tracks and would even prefer to work with a bad drummer that can’t keep a steady beat. When working with real live people there are all sorts of additional cues to keeping in time, and of course there is the “feel” of the music, which is absent from a click track. When I first tried playing with a click track I could have sworn that the click was not keeping a steady beat. I found that after a substantial amount of practising with a metronome, my “faulty” software suddenly got much better :smiley:

It depends on what I’m doing.
For casual use I generally don’t bother. My usual laptop is quite old, but runs well and quite efficiently. I don’t generally get timing problems.
If I’m doing an important recording, I will usually be starting a new session on the computer, so there isn’t anything else running anyway. I’m usually on Linux, so logging out and back in will start a new session. When I was on Windows I would generally do a reboot.

Security products can sometimes cause problems. We’ve recently seen some issues with some Norton products due to the security program “cleaning redundant files” during the recording session. Previously we have seen problems with other security programs scanning Audacity’s _data folder during a recording session. Such problems can usually be resolved by configuring the security program appropriately. Temporarily turning off security products (with the network disconnected) can be an effective way to determine if the security program is causing problems. If it is, then it is better to find out how to fix that so that you don’ need to keep disabling it.

Although it seems to be rare, I once had a problem that was caused by the network connection itself. When the network was enabled I would sometimes find that the recording would intermittently “skip”, causing the recorded track to play too fast with rapid “clicks” in the sound. That turned out to be a hardware issue - the network card was conflicting with my sound card. The tell-tail sign of that type of problem is the “clicks”, though there are many other things that can cause clicking.

The more tracks there are in the project, the more demand there is on the computer. Long tracks can also cause slow downs. On a fairly modern computer there should be few such problems for 3 or 4 tracks under half an hour. There is a huge amount of variation from one computer to another, for example I’ve done quite a few projects with more than 30 tracks on quite low specification hardware with no problem at all. The limit for my elderly low budget (Linux) laptop appears to be a bit in excess of 100 x 3 minute stereo tracks, though other users on better hardware have reported less good performance. There are a lot of optimization tips in this article:

Audacity should work fine with a conventional hdd drive (internal, not USB or network).

Thanks for the replies both you guys. I managed to get through recording a couple of simple numbers with only a couple of tracks yesterday but my technique was a bit clunky and laughably “manual”! Anyway here is another long diatribe with some results of testing. I think I’ll have to get on and use it after this and just learn to live with things I found until explanations pop up. Thanks for your patience this far.

The effect does still seem to be there but was less yesterday. I start with a click track and lay down a rhythm track over that. This drifts in and out very slightly over the length of the track, which I would now say is most likely at least partially down to me. But when I lay down another track things do seem to get a tad worse. It’s more noticeable when it’s 2 real tracks against each other and I can’t believe that is all down to me being out, I’m pretty experienced at playing with others without problems and the first track effectively takes the load off relying on the click track. If I check, it often drifts out very noticeably in the middle, maybe up to 250-500ms, but is back in at the end. I can correct the growing delay in the middle, say by time-shifting the later section of the second track when it becomes noticeable, but that of course puts the end of the track out and I end up chasing my tail.

I had set up the latency correction by the established click, re-record and measure difference method in advance but again, it did vary a little each time I lay down a track and I was constantly manually correcting with timeshift and readjusting it slightly in preferences. Starting at say 236ms, the next track was then at about 255ms, and so on. I have just completed another test by recording a 2min click track to other successive tracks muting them each time and I have found some strange stuff. The latency starts at 255ms between the Click track and Track 1. Track 2 is immeasurable timewise but 6 samples ahead of Track 1, yes, the latency decreases. Track 3 is then 2ms/92 samples ahead of Track 1, Track 4 is also 92 samples ahead, Track 5 then slides to 56 samples ahead, Track 5 is 56 samples ahead and finally Track 6 is 57 samples. I then turned on all of the tracks but turned the volume of everything but the Click track down low and recorded another track figuring to maybe increase the processing overhead. Still 1-2% CPU on Audacity’s process and whaddya know, only 4 samples difference between Track 7 and Track 1 with Track 7 still ahead. So does it seem that there is some very small random effect at work here, much smaller than anything I was originally experiencing? I don’t see why the first track should be the worst for latency then successive tracks show slight variants less. I would have expected small differences maybe but I would have thought they would increase not decrease. Here is a screenshot to show this. Tracks are in order from top to bottom. Neither the mic nor the speaker were moved at all during this whole process.
Audacity tracks.jpg
These results are only out by a couple of msec of course and mean nothing in the real world, but I’m looking for a mechanism which may occasionally increase to audible levels and it’s escaping me completely when there is so little strain on resources. I was honestly surprised when I saw how little CPU time Audacity grabs and that the RAM used on startup was 5.8MB. Recording 2 mins of a track increased this to 9.3MB, after another track it was 11.4MB and after a third it was 12.4MB. There seems to be a big jump each time I start recording another track but it then drops considerably after a short while, possibly as it flushes data out to HDD? These figures make sense I hope and I am assuming they are roughly what would be expected?

Are there any other independent pieces in the Audacity system, (like Lame or jack), which may be causing a problem. If I’m honest, it’s so long since I installed it and got it working that I get confused between Audacity and EAC in relation to that aspect.

One other thing I am going to try next time is to increase the Audacity process priority to high from its current normal, (real time can cause problems in itself). I already have the process affinity set to all 4 CPUs. I will say that I don’t really expect this will have any effect. I’m also interested to put it on a much lower spec laptop and try recording onto that. The comparison should be interesting.

I’m beginning to think that, like Steve, the more I practice the more the software will settle down and behave as expected :sunglasses: . It will know when it’s licked!

I also have selected my system Solid State Drive for Audacity’s temp folder rather than a slower mechanical drive. Is this necessary as I don’t want to fill up the SSD with garbage?

The system in on the SSD? One way to easily triple the speed of a computer or better is start throwing SSDs at it. I have a similar laptop to one at work. They have a spinning drive and I popped for an SSD (Christmas, Birthday and St. Swithins Day). I can be finished and be drinking espresso in the cafeteria while their machine is still managing the work. It’s a very serious difference. I had to do something on their machine once and just in time stopped myself saying: “Is this thing broken?”


Audacity cleans up the temporary work as it goes, so unless you’re scoring a massive symphony, it should not be a big space issue.

You can do that feedback/sync trick several different ways.

But yes, if you pass this test multiple times with only millisecond drift errors, then you win. Most of us don’t have Digital Audio Workstations.

I never got used to playing with other humans, but I do play along with the internal rhythms in my keyboard, so I didn’t have any trouble adapting to a freakishly robotic click track. It worked just like my freakishly robotic Yamaha.


That’s not going to help, in fact it could be worse than leaving it on default/auto. Audacity is not multi-threaded so it can’t take advantage of multiple parallel cores. I’m on Linux and I just let the computer sort out which core to use. When giving Audacity something heavy to chew on (processing long tracks) I can monitor the CPU as watch it switch cores when one processor starts to get warm.

As far as I know, Windows defaults to enabling an application to use all processors.

So by default Windows would be doing for Audacity what you have Linux (Debian?) set to do.

@bordonbert, if you open the Windows Control Panel then open System then the “Advanced” section, then open the “Performance” settings and click the “Advanced” tab, you can set processor scheduling to adjust for best performance of programs instead of background processes. Sometimes this can help with dropouts or latency. It may be set to background processes by default on XP, I’m not sure.


I think that may be the wrong way round.

On Windows (XP), sound runs as a background service, so for audio performance issues it is usually best to prioritise background services. IIRC, the default on XP is to prioritise programs.
Ref tip 21:
and Step 9:

Thanks, Steve. Yes audio is still a background audio service in later Windows, too.

You may be right that XP is set to “Programs” by default - I don’t recall exactly how vanilla XP without service packs is set. Windows 7 and Windows 8 are set to “Programs” by default.

To some extent I stand by what I said, despite the Wiki and Ableton pages. It depends what’s going on and how programs are behaving.

I have had a couple of cases recently (on Vista and XP) where setting best performance to “Programs” fixed dropouts every six seconds where the users were working with large numbers of tracks. One of those users had a lot of programs and services running that they did not want to turn off.

If the issue is Audacity or other programs are being too slow because of what other services need to do, setting to “Programs” might help. Older Windows relies much more on services to do things than later Windows does, where many operations are now run as occasional scheduled tasks rather than running a service continually.

In sum, I think point 21 in the Wiki page should perhaps be more of a suggestion to see if changing that setting helps, at least on older Windows.

The suggestion on the Ableton page to disable Aero on Windows 7 (which applies to Vista too) is a good one.