PlayBack Vu-Meters

Do they “look ahead”???

I’ve been using N-Track for a while now, and this has happened since I first bought it. The Playback VU-Meter and the meters on the track mixer, are always 1-3 seconds ahead of the audio…

For example Im working on a song right now, on my track mixer, the meter for my “SNARE” channel goes up before the snare actually hits. This has never stopped me from working before but it’s really starting to bug me now. Is there a way to fix this? I’ve looked through the help file but its not really all that helpful IMO.

Also is N-Track able to work with MIDI controllers that use AUTOMATED faders? I was looking at the Behringer MIDI controllers and the automated faders seem like they’d make the mixing process a bit quicker and more fun altogether.

Hi budd:
We’ve had some discussion on the behaviour of the meters… And no real resolve was forth-comming…

However, the Meter’s response can be altered/changed by Right-clicking on them and playing with the configuering that is available, there… There’s lots to Pick-and-choose from in the meter config. panel…

I think we came to the conclusion that the meters responds to the latency of the system… Well, something, like that… But for sure, they do not respond, In-Phase… to the program material…


I don’t know what uncertainty you’re referring to, Bill, but you’re on the right track with your answer.

First, for playback meters, there’s an option, “playback meters anticipate output”. I believe this is unchecked by default, so playback meters are in sync with output from soundcard. I always turn it on. The advantage is that when playback meters are fed before conversion to soundcard format, they can show how far over 0dB (how far in the red) the signal went, which is very helpful.

With the option turned on, the amount of “anticipation” is reduced by reducing playback latency. The easiest way to do this is simply to use ASIO drivers – by itself that lowers the latency far enough to be imperceptible in this way (meter anticipation).

This will also reduce the amount of anticipation the track meters have.

If you don’t have ASIO drivers but have WDM, you can try them and reduce the buffering to make this delay between meter movement and sound output. But there is another possible factor here: plugin latency. Different plugins have different latencies, and in general you can’t reduce them by changing buffering settings. Frankly, I wouldn’t worry about this.

Finally, you may have noticed that there’s also a delay between making an adjustment to the mix and hearing the result. This is also caused by playback latency. Reducing it improves the “feel” of n-Track dramatically, IMHO – it feels more like hardware: changes you make take immediate effect.

The kind of latency we usually talk about here is when using LIVE mode, either to use a plugin synth or to feed an input signal to a plugin effect (e.g., guitar amp sim) while recording, and to hear the effect in the monitors. This has both components mentioned above plus a third, record latency.

Record latency is due to buffering between input and n-Track’s processing.
Plugin latency is due to buffering in a plugin. (Many plugins have little or no latency.)
Playback latency is due to buffering between n-Track’s processing (including plugins) and soundcard analog output.

Get the picture – latencies are caused by buffering. There’s another kind of buffering, disk buffering, that doesn’t contribute to latency.

Yup, it’s kinda complicated. IMHO, easier to understand the concepts than memorize the facts here:

- Analog signal goes into soundcard.
- Soundcard converst to digital and stuffs buffers. These buffers get filled at a constant rate.
- n-Track gets buffers from soundcard, feeds signal to plugins (if any) in buffers.
- n-Track delays tracks as necessary to compensate for longest chain of plugin latency, so tracks stay in sync
- n-Track sums tracks, groups, & aux buses, converts to output soundcard format, and fills playback buffers.
- Soundcard takes playback buffers and converts them to audio. This conversion happens at a constant rate.

The stuff inbetween the “constant rate” things above doesn’t have to happen at a constant rate. It can run in bursts, as long as it keeps up with both ends. The more buffering, the bigger these bursts can be, and the more time n-Track can get swapped out for the computer to do other things. but this also increases the end-to-end delay between signals coming in and signals going out. These delays are what we call “latency”.

Sorry, answered more than your question. Maybe this one belongs on the Wiki.

There are some facts I skirted above, due to stuff I can’t tell about n-Track from observing it, such as whether the buffers for n-Track processing are a third set, or they’re just the record or playback buffers (probably the playback buffers). Also, there’s a checkbox for “process in driver’s thread” which I think affects where certain conversions happen but I don’t know the details.

Definitely need to ‘Wiki-ize’ it LearJeff. This kind of thing comes up a lot. Many newbies and even some old pro’s don’t really understand buffering and latency. That’s as good a write-up as I have seen on the subject…